From sacadmin Wed Nov 26 12:16:06 2008 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAQKG6Bf018100; Wed, 26 Nov 2008 12:16:06 -0800 (PST) Received: (from jb25718@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id mAQKG67r018096; Wed, 26 Nov 2008 12:16:06 -0800 (PST) Date: Wed, 26 Nov 2008 12:16:06 -0800 (PST) From: Jordan Brown Message-Id: <200811262016.mAQKG67r018096@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Cc: cifs-eng@sun.com Subject: CIFS Client Message Signing [PSARC/2008/737 FastTrack timeout 12/08/2008] Status: RO Content-Length: 557 Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: CIFS Client Message Signing 1.2. Name of Document Author/Supplier: Author: Gordon Ross 1.3 Date of This Document: 26 November, 2008 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From sacadmin Thu Nov 27 00:23:55 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAR8Ntkc024082 for ; Thu, 27 Nov 2008 00:23:55 -0800 (PST) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAR8Ntf9038202 for ; Thu, 27 Nov 2008 00:23:55 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mAR8NoFn009204 for ; Thu, 27 Nov 2008 00:23:50 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KAZ00201GIP4900@fe-sfbay-10.sun.com> (original mail from Jordan.Brown@Sun.COM) for PSARC@sac.sfbay.sun.com; Thu, 27 Nov 2008 00:23:50 -0800 (PST) Received: from [127.0.0.1] ([68.122.68.237]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAZ00CMQGNPV150@fe-sfbay-10.sun.com>; Thu, 27 Nov 2008 00:23:49 -0800 (PST) Date: Thu, 27 Nov 2008 00:23:52 -0800 From: Jordan Brown Subject: CIFS Client Message Signing [PSARC/2008/737 FastTrack timeout 12/08/2008] In-reply-to: <200811262016.mAQKG67r018096@sac.sfbay.sun.com> Sender: Jordan.Brown@Sun.COM To: PSARC@sac.sfbay.sun.com Cc: cifs-eng@Sun.COM Message-id: <492E5918.3010008@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200811262016.mAQKG67r018096@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) Status: RO Content-Length: 4264 I am sponsoring the following for fast track approval. The timer expires 8 December 2008. --- This information is Copyright 2008 Sun Microsystems CIFS Client Message Signing Author: Gordon Ross 26 November, 2008 1. Technical Description Add "signing" support to the Solaris CIFS Client 2. Details 2.1 Background and motivation The Solaris CIFS Client [PSARC 2005/695] provides the ability to mount CIFS shares from Windows-compatible servers on Solaris. In this context, "SMB signing" refers to a message integrity system designed by Microsoft, further described here: Overview of Server Message Block signing http://support.microsoft.com/kb/887429 The use of SMB signing is negotiated between the client and server during connection initiation. Policy settings on both client and server influence the outcome of this negotiation. Either the client or server may require signing, but normally the signing policy is controlled from the server side because that method has the convenience of centralized administration. This case adds support for a new option named "signing" to the existing client-side options stored in SMF. The new "signing" option allows a system administrator to control the client-side policy for negotiation of SMB signing, in a way similar to that provided on Windows systems. Details of the new option are described in the the nsmbrc(4) manual page, which will be updated with this case. 3. Interface table 3.1 Exported Interfaces "signing" option Committed See nsmbrc(4) 3.2 Imported Interfaces (no change) 4. Documentation The nsmbrc(4) man page will be updated by CR 6720803. Here is a summary of the nsmbrc(4) changes: New parameter: signing Allowed in SMF only. (sharectl) Allowed in sections: default, $SERVER Allowed values: disabled, enabled, required Default value: disabled [Note 1] Example output of "sharectl get smbfs": [default] signing=required The definitions of the values are: disabled: Client does not use SMB signing unless the server requires signing. [Note 1] (This is the default value.) enabled: Client will use SMB signing if possible. required: Client requires SMB signing. Note: If a server has signing set to "disabled", then connections with this configuration will fail. These values are further explained here: Overview of Server Message Block signing http://support.microsoft.com/kb/887429 Support for SMB signing is required for interoperability with recent Windows servers. While SMB signing was originally intended to defend against man-in-the-middle (MITM) attacks, it is not recommended as a sole defense against such attacks because the message integrity system it uses is not considered cryptographically strong. See this page for details: [MS-SMB] Sec. 5.1 Security Considerations for Implementers http://msdn.microsoft.com/en-us/library/cc212610.aspx Better defense against MITM attack as well as "eavesdropping" is available with ipsec(7p) or Virtual Private Network (VPN) technologies. Note 1: Note that if the server requires signing, the Solaris CIFS client uses signing regardless of local settings. This is the same as with current Windows clients, per Microsoft Knowledge Base article 916846. See: http://support.microsoft.com/?kbid=916846 5. References Overview of Server Message Block signing http://support.microsoft.com/kb/887429 [MS-SMB] Sec. 3.2.4.2.3 User Authentication (signing) http://msdn.microsoft.com/en-us/library/cc212511.aspx [MS-SMB] Sec. 5.1 Security Considerations for Implementers http://msdn.microsoft.com/en-us/library/cc212610.aspx [MS-SMB] Appendix A: Windows Behavior (item 172) http://msdn.microsoft.com/en-us/library/cc212929.aspx#wb172 [MS-NLMP] NT LAN Manager (NTLM) Authentication Protocol http://msdn.microsoft.com/en-us/library/cc207842.aspx Microsoft Knowledge Base article 916846: http://support.microsoft.com/?kbid=916846 From sacadmin Thu Nov 27 01:45:42 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAR9jf1T025570 for ; Thu, 27 Nov 2008 01:45:41 -0800 (PST) Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.EU.Sun.COM [192.18.6.24]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAR9jflA061129 for ; Thu, 27 Nov 2008 01:45:41 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mAR9jZ7O005914 for ; Thu, 27 Nov 2008 09:45:35 GMT Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KAZ00I01K5WI900@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC@sac.sfbay.sun.com; Thu, 27 Nov 2008 09:45:35 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAZ00EBFKFV3P50@fe-emea-10.sun.com>; Thu, 27 Nov 2008 09:45:32 +0000 (GMT) Date: Thu, 27 Nov 2008 09:45:31 +0000 From: Darren J Moffat Subject: Re: CIFS Client Message Signing [PSARC/2008/737 FastTrack timeout 12/08/2008] In-reply-to: <492E5918.3010008@sun.com> Sender: Darren.Moffat@Sun.COM To: Jordan Brown Cc: PSARC@sac.sfbay.sun.com, cifs-eng@Sun.COM Message-id: <492E6C3B.5010809@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200811262016.mAQKG67r018096@sac.sfbay.sun.com> <492E5918.3010008@sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081104) Status: RO Content-Length: 682 I understand this case is about the CIFS client but in the interest of "the bigger architectural picture" does the Solaris CIFS server support this already or is there a corresponding case for the server side ? While this is an already existing protocol and thus the crypto suites are predetermined I would still like this case to actually enumerate how the signing is done. In particular what crypto algorithms are used, where the key material for the signing comes from and if any key material is stored on persistent storage. Also does this case use the crypto framework APIs for the implementation of the crypto algorithms needed for the signing ? -- Darren J Moffat From sacadmin Thu Nov 27 02:14:35 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mARAEZH8028987 for ; Thu, 27 Nov 2008 02:14:35 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mARAEYEB025859 for ; Thu, 27 Nov 2008 02:14:34 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mARAEYuG015910 for ; Thu, 27 Nov 2008 10:14:34 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KAZ00001LLR0600@mail-amer.sun.com> (original mail from amw@Sun.COM) for PSARC@sac.sfbay.sun.com; Thu, 27 Nov 2008 03:14:34 -0700 (MST) Received: from TOSHIBA ([129.150.16.8]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAZ00AKFLRPSLF0@mail-amer.sun.com>; Thu, 27 Nov 2008 03:14:14 -0700 (MST) Date: Thu, 27 Nov 2008 02:14:13 -0800 From: "Alan.M.Wright" Subject: Re: CIFS Client Message Signing [PSARC/2008/737 FastTrack timeout 12/08/2008] Sender: Alan.M.Wright@Sun.COM To: Darren J Moffat , Jordan Brown Cc: PSARC@sac.sfbay.sun.com, cifs-eng@Sun.COM Message-id: <8D7136E01FD04EFA8D083DC27880D5E7@TOSHIBA> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5512 Content-type: text/plain; reply-type=response; charset=iso-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <200811262016.mAQKG67r018096@sac.sfbay.sun.com> <492E5918.3010008@sun.com> <492E6C3B.5010809@Sun.COM> Status: RO Content-Length: 1493 Darren J Moffat wrote: >I understand this case is about the CIFS client but in the interest of "the >bigger architectural picture" does the Solaris CIFS server support this >already or is there a corresponding case for the server side ? Yes, the CIFS server already supports signing: both when clients connect to the CIFS server and when the CIFS server communicates with domain controllers, i.e. the CIFS server already does the client-side signing being presented here. This case is a step towards eliminating the need for the CIFS server to communicate directly with domain controllers and rely on the CIFS client for that purpose. > While this is an already existing protocol and thus the crypto suites are > predetermined I would still like this case to actually enumerate how the > signing is done. In particular what crypto algorithms are used, where the > key material for the signing comes from and if any key material is stored > on persistent storage. The algorithm is described in the Microsoft references and in the CIFS service case (PSARC/2006/715) section 3.1.5 (SMB Signing) and 3.6.1 (SMB Client): http://sac.sfbay.sun.com/Archives/CaseLog/arc/PSARC/2006/715/final.materials/cifs-design_1_1.pdf > Also does this case use the crypto framework APIs for the implementation > of the crypto algorithms needed for the signing ? I believe the answer is yes (this was a project requirement) but we'll confirm that. Alan > Darren J Moffat > From sacadmin Thu Nov 27 10:00:17 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mARI0HLc020903 for ; Thu, 27 Nov 2008 10:00:17 -0800 (PST) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mARI0GeD055001 for ; Thu, 27 Nov 2008 10:00:17 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mARI0BXk026160 for ; Thu, 27 Nov 2008 10:00:11 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KB00090179AMU00@fe-sfbay-10.sun.com> (original mail from Jordan.Brown@Sun.COM) for PSARC@sac.sfbay.sun.com; Thu, 27 Nov 2008 10:00:11 -0800 (PST) Received: from [127.0.0.1] ([68.122.68.237]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KB000B2Q7CBKZ70@fe-sfbay-10.sun.com>; Thu, 27 Nov 2008 10:00:11 -0800 (PST) Date: Thu, 27 Nov 2008 10:00:15 -0800 From: Jordan Brown Subject: Re: CIFS Client Message Signing [PSARC/2008/737 FastTrack timeout 12/08/2008] In-reply-to: <492E6C3B.5010809@Sun.COM> Sender: Jordan.Brown@Sun.COM To: Darren J Moffat Cc: PSARC@sac.sfbay.sun.com, cifs-eng@Sun.COM Message-id: <492EE02F.1080907@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200811262016.mAQKG67r018096@sac.sfbay.sun.com> <492E5918.3010008@sun.com> <492E6C3B.5010809@Sun.COM> User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) Status: RO Content-Length: 811 Darren J Moffat wrote: > While this is an already existing protocol and thus the crypto suites > are predetermined I would still like this case to actually enumerate > how the signing is done. In particular what crypto algorithms are > used, where the key material for the signing comes from and if any key > material is stored on persistent storage. As Alan said, the algorithms are in the MS documentation. However, a brief summary: A random signing key is generated during the NTLM authentication phase and passed across the wire encrypted under a derivative of the user password. The signature is the MD5 of the concatenation of the signing key, a session identifier, and the message body. I am told that Kerberos is also supported, and I assume that there the Kerberos session key is used. From sacadmin Thu Nov 27 10:24:03 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mARIO3F4021807 for ; Thu, 27 Nov 2008 10:24:03 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mARIO3Mh002259 for ; Thu, 27 Nov 2008 10:24:03 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mARIO2eN016574 for ; Thu, 27 Nov 2008 18:24:02 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KB000G018A5ZR00@mail-amer.sun.com> (original mail from Gordon.Ross@Sun.COM) for PSARC@sac.sfbay.sun.com; Thu, 27 Nov 2008 11:24:02 -0700 (MST) Received: from [192.168.1.186] ([75.67.12.95]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KB000EHP8G1NL10@mail-amer.sun.com>; Thu, 27 Nov 2008 11:24:02 -0700 (MST) Date: Thu, 27 Nov 2008 13:23:56 -0500 From: Gordon Ross Subject: Re: CIFS Client Message Signing [PSARC/2008/737 FastTrack timeout 12/08/2008] In-reply-to: <492E6C3B.5010809@Sun.COM> Sender: Gordon.Ross@Sun.COM To: Darren J Moffat Cc: Jordan Brown , PSARC@sac.sfbay.sun.com, cifs-eng@Sun.COM Message-id: <6986C7AE-96BC-453D-803C-EE125F7C79F7@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.753.1) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <200811262016.mAQKG67r018096@sac.sfbay.sun.com> <492E5918.3010008@sun.com> <492E6C3B.5010809@Sun.COM> Status: RO Content-Length: 1246 On Nov 27, 2008, at 4:45 AM, Darren J Moffat wrote: > I understand this case is about the CIFS client but in the interest > of "the bigger architectural picture" does the Solaris CIFS server > support this already or is there a corresponding case for the > server side ? Yes, as Alan explained. > While this is an already existing protocol and thus the crypto > suites are predetermined I would still like this case to actually > enumerate how the signing is done. In particular what crypto > algorithms are used, where the key material for the signing comes > from and if any key material is stored on persistent storage. I'm not sure how this is relevant, since we have no choice but protocol compliance here. But that said, here are some references on the details of "SMB signing": [MS-SMB] Sec. 3.1.4.1 Sending Any Message http://msdn.microsoft.com/en-us/library/cc212475.aspx [MS-SMB] Sec. 3.1.5.1 Receiving Any Message http://msdn.microsoft.com/en-us/library/cc212477.aspx [MS-SMB] Sec. 4.3 Message Signing Example http://msdn.microsoft.com/en-us/library/cc246472.aspx > Also does this case use the crypto framework APIs for the > implementation of the crypto algorithms needed for the signing ? Yes. Gordon From Jordan.Brown@Sun.COM Mon Dec 1 11:15:59 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mB1JFxf8023938 for ; Mon, 1 Dec 2008 11:15:59 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mB1JFwn1017646 for ; Mon, 1 Dec 2008 11:15:58 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mB1JFrNm003537 for ; Mon, 1 Dec 2008 11:15:53 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KB700901OJ8EJ00@fe-sfbay-10.sun.com> (original mail from Jordan.Brown@Sun.COM) for PSARC-ext@sac.sfbay.sun.com; Mon, 01 Dec 2008 11:15:53 -0800 (PST) Received: from [129.145.155.63] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KB7001UDPIB7D10@fe-sfbay-10.sun.com>; Mon, 01 Dec 2008 11:15:52 -0800 (PST) Date: Mon, 01 Dec 2008 11:15:47 -0800 From: Jordan Brown Subject: CIFS Client Message Signing [PSARC/2008/737 FastTrack timeout 12/08/2008] In-reply-to: <200811262016.mAQKG67r018096@sac.sfbay.sun.com> Sender: Jordan.Brown@Sun.COM To: PSARC-ext@sac.sfbay.sun.com Cc: cifs-eng@Sun.COM Message-id: <493437E3.9090807@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT References: <200811262016.mAQKG67r018096@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 4443 [ Sorry, sent to the wrong alias, resending to psarc-ext. I'll forward the discussion so far. Please watch for replying to the original message and change it to psarc-ext. ] I am sponsoring the following for fast track approval. The timer expires 8 December 2008. --- This information is Copyright 2008 Sun Microsystems CIFS Client Message Signing Author: Gordon Ross 26 November, 2008 1. Technical Description Add "signing" support to the Solaris CIFS Client 2. Details 2.1 Background and motivation The Solaris CIFS Client [PSARC 2005/695] provides the ability to mount CIFS shares from Windows-compatible servers on Solaris. In this context, "SMB signing" refers to a message integrity system designed by Microsoft, further described here: Overview of Server Message Block signing http://support.microsoft.com/kb/887429 The use of SMB signing is negotiated between the client and server during connection initiation. Policy settings on both client and server influence the outcome of this negotiation. Either the client or server may require signing, but normally the signing policy is controlled from the server side because that method has the convenience of centralized administration. This case adds support for a new option named "signing" to the existing client-side options stored in SMF. The new "signing" option allows a system administrator to control the client-side policy for negotiation of SMB signing, in a way similar to that provided on Windows systems. Details of the new option are described in the the nsmbrc(4) manual page, which will be updated with this case. 3. Interface table 3.1 Exported Interfaces "signing" option Committed See nsmbrc(4) 3.2 Imported Interfaces (no change) 4. Documentation The nsmbrc(4) man page will be updated by CR 6720803. Here is a summary of the nsmbrc(4) changes: New parameter: signing Allowed in SMF only. (sharectl) Allowed in sections: default, $SERVER Allowed values: disabled, enabled, required Default value: disabled [Note 1] Example output of "sharectl get smbfs": [default] signing=required The definitions of the values are: disabled: Client does not use SMB signing unless the server requires signing. [Note 1] (This is the default value.) enabled: Client will use SMB signing if possible. required: Client requires SMB signing. Note: If a server has signing set to "disabled", then connections with this configuration will fail. These values are further explained here: Overview of Server Message Block signing http://support.microsoft.com/kb/887429 Support for SMB signing is required for interoperability with recent Windows servers. While SMB signing was originally intended to defend against man-in-the-middle (MITM) attacks, it is not recommended as a sole defense against such attacks because the message integrity system it uses is not considered cryptographically strong. See this page for details: [MS-SMB] Sec. 5.1 Security Considerations for Implementers http://msdn.microsoft.com/en-us/library/cc212610.aspx Better defense against MITM attack as well as "eavesdropping" is available with ipsec(7p) or Virtual Private Network (VPN) technologies. Note 1: Note that if the server requires signing, the Solaris CIFS client uses signing regardless of local settings. This is the same as with current Windows clients, per Microsoft Knowledge Base article 916846. See: http://support.microsoft.com/?kbid=916846 5. References Overview of Server Message Block signing http://support.microsoft.com/kb/887429 [MS-SMB] Sec. 3.2.4.2.3 User Authentication (signing) http://msdn.microsoft.com/en-us/library/cc212511.aspx [MS-SMB] Sec. 5.1 Security Considerations for Implementers http://msdn.microsoft.com/en-us/library/cc212610.aspx [MS-SMB] Appendix A: Windows Behavior (item 172) http://msdn.microsoft.com/en-us/library/cc212929.aspx#wb172 [MS-NLMP] NT LAN Manager (NTLM) Authentication Protocol http://msdn.microsoft.com/en-us/library/cc207842.aspx Microsoft Knowledge Base article 916846: http://support.microsoft.com/?kbid=916846 From Jordan.Brown@Sun.COM Mon Dec 1 11:21:42 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mB1JLfHq023960 for ; Mon, 1 Dec 2008 11:21:42 -0800 (PST) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mB1JLfDe016252 for ; Mon, 1 Dec 2008 11:21:41 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mB1JLa4k021519 for ; Mon, 1 Dec 2008 11:21:36 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KB700901OJ8EJ00@fe-sfbay-10.sun.com> (original mail from Jordan.Brown@Sun.COM) for PSARC-ext@sac.sfbay.sun.com; Mon, 01 Dec 2008 11:21:36 -0800 (PST) Received: from [129.145.155.63] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KB7001UOPR57D40@fe-sfbay-10.sun.com> for PSARC-ext@sac.sfbay.sun.com; Mon, 01 Dec 2008 11:21:06 -0800 (PST) Date: Mon, 01 Dec 2008 11:21:05 -0800 From: Jordan Brown Subject: CIFS Client Message Signing [PSARC/2008/737 FastTrack timeout 12/08/2008] Sender: Jordan.Brown@Sun.COM To: PSARC-ext@sac.sfbay.sun.com Message-id: <49343921.7040409@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 5605 [ The conversation so far. Again, please watch replies and change psarc@sun.com to psarc-ext@sun.com. ] Date: Thu, 27 Nov 2008 09:45:31 +0000 From: Darren J Moffat Subject: Re: CIFS Client Message Signing [PSARC/2008/737 FastTrack timeout 12/08/2008] To: Jordan Brown Cc: PSARC@sac.sfbay.sun.com, cifs-eng@Sun.COM Message-id: <492E6C3B.5010809@Sun.COM> I understand this case is about the CIFS client but in the interest of "the bigger architectural picture" does the Solaris CIFS server support this already or is there a corresponding case for the server side ? While this is an already existing protocol and thus the crypto suites are predetermined I would still like this case to actually enumerate how the signing is done. In particular what crypto algorithms are used, where the key material for the signing comes from and if any key material is stored on persistent storage. Also does this case use the crypto framework APIs for the implementation of the crypto algorithms needed for the signing ? -- Darren J Moffat Date: Thu, 27 Nov 2008 02:14:13 -0800 From: "Alan.M.Wright" Subject: Re: CIFS Client Message Signing [PSARC/2008/737 FastTrack timeout 12/08/2008] To: Darren J Moffat , Jordan Brown Cc: PSARC@sac.sfbay.sun.com, cifs-eng@Sun.COM Message-id: <8D7136E01FD04EFA8D083DC27880D5E7@TOSHIBA> Darren J Moffat wrote: >I understand this case is about the CIFS client but in the interest of "the >bigger architectural picture" does the Solaris CIFS server support this >already or is there a corresponding case for the server side ? Yes, the CIFS server already supports signing: both when clients connect to the CIFS server and when the CIFS server communicates with domain controllers, i.e. the CIFS server already does the client-side signing being presented here. This case is a step towards eliminating the need for the CIFS server to communicate directly with domain controllers and rely on the CIFS client for that purpose. > While this is an already existing protocol and thus the crypto suites are > predetermined I would still like this case to actually enumerate how the > signing is done. In particular what crypto algorithms are used, where the > key material for the signing comes from and if any key material is stored > on persistent storage. The algorithm is described in the Microsoft references and in the CIFS service case (PSARC/2006/715) section 3.1.5 (SMB Signing) and 3.6.1 (SMB Client): http://sac.sfbay.sun.com/Archives/CaseLog/arc/PSARC/2006/715/final.materials/cifs-design_1_1.pdf > Also does this case use the crypto framework APIs for the implementation > of the crypto algorithms needed for the signing ? I believe the answer is yes (this was a project requirement) but we'll confirm that. Alan > Darren J Moffat > Date: Thu, 27 Nov 2008 10:00:15 -0800 From: Jordan Brown Subject: Re: CIFS Client Message Signing [PSARC/2008/737 FastTrack timeout 12/08/2008] To: Darren J Moffat Cc: PSARC@sac.sfbay.sun.com, cifs-eng@Sun.COM Darren J Moffat wrote: > While this is an already existing protocol and thus the crypto suites > are predetermined I would still like this case to actually enumerate > how the signing is done. In particular what crypto algorithms are > used, where the key material for the signing comes from and if any key > material is stored on persistent storage. As Alan said, the algorithms are in the MS documentation. However, a brief summary: A random signing key is generated during the NTLM authentication phase and passed across the wire encrypted under a derivative of the user password. The signature is the MD5 of the concatenation of the signing key, a session identifier, and the message body. I am told that Kerberos is also supported, and I assume that there the Kerberos session key is used. Date: Thu, 27 Nov 2008 13:23:56 -0500 From: Gordon Ross Subject: Re: CIFS Client Message Signing [PSARC/2008/737 FastTrack timeout 12/08/2008] To: Darren J Moffat Cc: Jordan Brown , PSARC@sac.sfbay.sun.com, cifs-eng@Sun.COM Message-id: <6986C7AE-96BC-453D-803C-EE125F7C79F7@sun.com> On Nov 27, 2008, at 4:45 AM, Darren J Moffat wrote: > I understand this case is about the CIFS client but in the interest > of "the bigger architectural picture" does the Solaris CIFS server > support this already or is there a corresponding case for the > server side ? Yes, as Alan explained. > While this is an already existing protocol and thus the crypto > suites are predetermined I would still like this case to actually > enumerate how the signing is done. In particular what crypto > algorithms are used, where the key material for the signing comes > from and if any key material is stored on persistent storage. I'm not sure how this is relevant, since we have no choice but protocol compliance here. But that said, here are some references on the details of "SMB signing": [MS-SMB] Sec. 3.1.4.1 Sending Any Message http://msdn.microsoft.com/en-us/library/cc212475.aspx [MS-SMB] Sec. 3.1.5.1 Receiving Any Message http://msdn.microsoft.com/en-us/library/cc212477.aspx [MS-SMB] Sec. 4.3 Message Signing Example http://msdn.microsoft.com/en-us/library/cc246472.aspx > Also does this case use the crypto framework APIs for the > implementation of the crypto algorithms needed for the signing ? Yes. Gordon From Jordan.Brown@Sun.COM Wed Dec 3 10:12:57 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mB3ICvm3014973 for ; Wed, 3 Dec 2008 10:12:57 -0800 (PST) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mB3ICvZU016370 for ; Wed, 3 Dec 2008 10:12:57 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mB3ICqfc029905 for ; Wed, 3 Dec 2008 10:12:52 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KBB00H019UFA400@fe-sfbay-09.sun.com> (original mail from Jordan.Brown@Sun.COM) for PSARC-ext@sac.sfbay.sun.com; Wed, 03 Dec 2008 10:12:52 -0800 (PST) Received: from [129.145.155.63] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KBB00CL4BWSPW40@fe-sfbay-09.sun.com> for PSARC-ext@sac.sfbay.sun.com; Wed, 03 Dec 2008 10:12:28 -0800 (PST) Date: Wed, 03 Dec 2008 10:12:28 -0800 From: Jordan Brown Subject: 2008/737 CIFS client signing - approved Sender: Jordan.Brown@Sun.COM To: PSARC-ext@sac.sfbay.sun.com Message-id: <4936CC0C.1080508@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 49 This case was approved at today's PSARC meeting.