We have changes for the OpenSolaris CIFS client that implement SMB "signing". For an Overview of SMB signing, see: http:// support.microsoft.com/kb/887429 Our "request to integrate" (RTI) review process led to some questions about what policy controls the client should offer, who should be allowed to adjust them, and what the default values should be. These questions caused more controversy than I expected, so I'd appreciate comments from this community on the issues below. 1-8 are background, 9-11 are open issues.
1: What is SMB signing? SMB signing is a message integrity system designed to defend against "man-in-the-middle" attacks. With SMB signing, both client and server include an 8-byte signature in messages they send, and verify the signature in messages they receive. 2: When is SMB signing used? SMB signing is negotiated during connection setup. The server sends two flags to the client: "enable", and "require". The "enable" flag means the server offers signing (at the client's option). The "require" flag means the server will refuse further communication on the connection unless the client uses SMB signatures. The client determines whether it should sign messages based on a combination of client-side policy settings and the two flags it receives from the server. This negotiation mechanism allows selective use of SMB signing in a network where there may be older clients or servers that do not support SMB signing. When site policy demands use of SMB signing, that policy is normally enforced by setting servers to require SMB signing. When all servers require signing, the signing policy settings on the clients become irrelevant. 3: Is SMB signing effective? One interesting side effect of allowing negotiation of signing to accommodate older clients or servers is that it can make SMB signatures ineffective at defending against man-in-the-middle attacks. If neither client nor server requires security signatures, a man-in-the-middle can intercept the negotiation of signing and indicate to both endpoints that their peer does not support SMB signatures. Therefore, SMB signing is only effective against man-in- the-middle attacks if at least one side is configured to require signing. 4: What is the performance cost of SMB signing? Most implementations suffer some performance loss when using SMB signing. For example, in this article: http://technet.microsoft.com/en-us/ library/cc728025.aspx Microsoft warns that "Using SMB packet signing can impose up to a 15 percent performance hit on file service transactions." The reason for the performance "hit" is due in part to computation of the signatures, but also because many servers (including all Windows servers) must reduce the negotiated maximum transfer size when using signatures. This typically means 4 times as many network round trips with signing. 5: What policy settings are provided to control signing? Windows systems have four policy settings to control signing; two for the server side and two for the client side. These policy settings are summarized below. The values for these policies are subject to the normal policy inheritance mechanisms supported by Windows (not described here). For details, see: http://support.microsoft.com/kb/ 887429 Client Microsoft network client: Digitally sign communications (always) Microsoft network client: Digitally sign communications (if server agrees) Server Microsoft network server: Digitally sign communications (always) Microsoft network server: Digitally sign communications (if client agrees) The above pairs of boolean settings both amount to a three-valued option. For convenience the three (useful) settings are described as follows: disabled: don't offer SMB signatures (but see "If Required" below) enabled: offer SMB signatures, but don't drop the connection if the peer can't sign. required: offer SMB signatures, and drop the connection if the peer doesn't sign. Most non-Windows SMB implementations support two parameters to control signing, one for the server side and one for the client, where each has three possible values as described above: "disabled", "enabled", "required". 6: How do the policy settings affect negotiation of SMB signing? The outcome of negotiation of SMB signing is described in this table: [Ref: Windows Server Protocols: MS-SMB, sec. 3.2.4.2.3 ] http://msdn.microsoft.com/en-us/library/cc212511.aspx http://msdn.microsoft.com/en-us/library/cc212929.aspx Srv/Cli | Required | Enabled | If Required | Disabled ------------+----------+------------+-------------+----------- Required | Signed | Signed | Signed | Blocked [1] ------------+----------+------------+-------------+----------- Enabled | Signed | Signed | Not Signed | Not Signed ------------+----------+------------+-------------+----------- If Required | Signed | Not Signed | Not Signed | Not Signed ------------+----------+------------+-------------+----------- Disabled | Blocked | Not Signed | Not Signed | Not Signed [1] Note that Windows 2003 and later don't really implement the "Disabled" column at the far right, even though the description of the policy settings implies that. Instead, Windows now implements the "If Required" column, meaning that modern Windows clients are always willing to use SMB signatures when the server requires them, regardless of client policy settings. 7: What are the default policy settings? On Windows domain controllers (authentication servers), the default is to require SMB signatures. On other Windows servers, the default is to offer but not require SMB signatures. On Windows clients, the default is to offer but not require SMB signatures. Signing policy defaults on non-Windows systems vary, but on servers "disabled" or "enabled" are common defaults, and on clients "if required" is common. 8: How do option settings work in the OpenSolaris CIFS client? Most option settings used by the OpenSolaris CIFS client use a precedence system where settings in a more narrow scope override those set in wider scopes. Option settings may come from the following places, in precedence order: Command line options Per-user settings from $HOME/.nsmbrc System-wide settings from "sharectl get smbfs" Compiled-in defaults. Most option settings are taken from the first place found in the above list. Some options are supported only system-wide (sharectl), where those options affect components common to multiple Unix users. (NetBIOS settings are an example.) 9: What signing policy options should our CIFS client offer? The initial proposal was to add one option named "signing" with the values: disabled: don't use SMB signatures unless the server requires them. enabled: use SMB signatures if the server supports them. required: use SMB signatures. If the server doesn't support them, give up. One question raised was: "Why have this option at all?" That's a good question. One could do without this option. For example, the Apple/Darwin CIFS client does not provide an option like this, and always uses the policy "Sign if the server requires it". The option may be useful for diagnostic purposes, i.e. "Is this problem affected by turning signing on or off?" or perhaps for testing in a transitional environment. 10: What should be the default value for the client signing options? The initial proposal was to have the (compiled-in) default value be: "disabled" (meaning "Sign if the server requires it"). That default introduces the least change of behavior to the client. (It's behavior would only change when connecting to a server that requires signing.) There have been suggestions to make "enabled" the default, mostly because that's what Windows clients do. Unfortunately, that does not help defend against man-in-the-middle attacks (see issue 3), and comes at significant performance cost (see issue 4), so using this as a default gives you all of the cost and none of the benefit. The only apparent usefulness of the "enabled" setting on clients is for testing in a transitional environment. There have also been suggestions to make "required" the default setting. That would be more secure, but is unfortunately impractical due to the need to communicate with older servers. (And again, a "signing required" policy is normally enforced on servers.) Given the above, making the default "sign if the server requires it" still seems like a good choice. Comments? 11: Who should be able to adjust the signing options? The initial proposal allowed the new "signing" parameter to be set in either system-wide or per-user settings. We can allow per-user control here because each Unix user has their own connections in the CIFS client, completely segregated from other Unix users. If this option is found in per-user settings, it affects only that user. It has been suggested that there is no usefulness in allowing the signing option in per-user settings. Maybe it is for test and problem diagnosis, i.e. "Does this problem change if I turn signing on or off?" A person doing such problem diagnosis might not want to modify the system-wide option for their experiments. Would others find a per-user option useful? It has also been suggested that we should not let normal users have any control over how the CIFS client sets up and uses its connections, because to do so amounts to giving users privilege that should be restricted to an administrator. That restriction may be desirable, but we already grant this privilege to normal users by letting unprivileged programs initiate network connections. Since no special privilege is required for setting up a connection to a CIFS server, and ordinary user programs (i.e. Samba smbclient) can do this any way they like, a signing option would not grant any new privilege. Is a per-user option expensive to support? Hard to say. As long as there are any user options, one support question will need to be: "Does the problem happen if you remove your $HOME/.nsmbrc file or rename it?" Is that expensive? It seems that the question of whether to allow the signing option in per-user settings boils down to a judgement call: Would it's benefit outweigh it's cost? Comments? _______________________________________________ cifs-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
