From: SMTP%"CIFS@discuss.microsoft.com" 3-FEB-1998 08:27:41.62 To: CIFS@DISCUSS.MICROSOFT.COM CC: Subj: Re: CIFS auth (was: new CIFS I-D) Paul wrote: > It's not supposed to be. The intent is to make CIFS be independent of the > authentication protocols. Our clients and servers will use GSS framing via > OIDs for the blobs (see below) -- but other compliant implementations of > CIFS can use any mechanism they want, as long as both client and server > agree. History is repeating itself! Those of you with a copy of the X/Open SMB spec from 1992 might look at section 11.2, the SMBsecpkgX specification (page 139). This provided a way for the client and server to agree on a authentication protocol. The reason this never took off (although apparently IBM implemented it in Warp?) is that the Microsoft clients didn't implement it. The survival of any feature in SMB is inimately tied to Microsofts implementation. The reason I'm bringing this up is that I don't think a generic authentication negotiation really buys us anything except the ability to use the authentication mechanisms that WinXX supports. Now that we are revamping the authentication mechanisms in this protocol what I would really like to see is something that offers true interoperability while maintaining good security. I think there is a mechanism that can achieve this. A major problem with the current (and all proposed) authentication mechanisms is that it ties the client and the server to use the same authentication system. For example, to use the NTLM authentication in a SMB server you have to implement a password backend (database) that stores the NTLM hashes. It is cryptographically impossible to use the Unix hashes (or anything else) with NTLM authentication. Similarly with the proposed scheme. Although the scheme is much more sophisticated it still suffers from the same limitation. The server cannot use an existing backend authentication system, it must implement a new security database that offers the information needed for the protocol. This means that systems that currently use AFS, DSS, NIS+ or other backends lose out badly. The solution to these problems is for the server to obtain from the client the plaintext password. This does not mean we have to have plaintext on the wire, it just means that we must go to a public key based authentication system. Here is an outline of a system that will address this problem. It is not a novel system (see, for example, the ssh protocol): 1) client contacts server 2) server sends its public key to the client 3) client encrypts the plaintext password and a random session key using the supplied public key and sends it to the server 4) server decrypts the password using its private key. The server uses this password to authenticate the client against whatever backend system the server has. 5) server sends yes/no answer along with a random session key encrypted using the clients session key 6) further messages are signed (or possibly encrypted) using the two session keys The only major weakness with the above as it stands is that it does not offer any server authentication, a man-in-the-middle can attack this easily. This is mostly solved by requiring that the client store the servers public key after a successful connection is made. Then we add a new step: 2.5) client compares the public key with a stored public key (if available) and if they do not match then the client must either abort the connection or prompt the user for confirmation, making it clear that the session may have been hijacked. With this additional step the only hole is the initial connection that establishes the servers public key. Most sites would find this acceptable although a simple mechanism (perhaps using a floppy) for transferring public keys would be nice. There are several major advantages to the above authentication system: 1) the server is no longer tied to using the same authentication backend as the client. Servers can upgrade their security systems independently of this protocol. 2) the session keys (used to sign/encrypt the messages) are not available to anyone sniffing the session 3) the server does not need to store plain text passwords on disk (unlike the current system) 4) the password is not available to anyone sniffing the session There are some patent issues to address but I think they are surmountable. There is one more thing that would need to be added (which I've mentioned before). We would need an error code that is applicable to any SMB which says "new authentication required". This would allow servers to cope with ticket expiry if their backend authentication system has that concept. This error code is sorely needed no matter what authentication system we go with. Andrew - ---------------------------------------------------------------- Users Guide http://www.microsoft.com/sitebuilder/resource/mailfaq.asp contains important info including how to unsubscribe. Save time, search the archives at http://discuss.microsoft.com/archives/index.html ================== RFC 822 Headers ================== Return-Path: everhart@mail09.mitre.org Received: by norlmn.gce.com (UCX V4.1-12C, OpenVMS E7.1-1H1 Alpha); Tue, 3 Feb 1998 08:20:06 -0500 Received: from mbunix.mitre.org (mbunix.mitre.org [129.83.20.100]) by mercury.mv.net (8.8.8/mem-971025) with ESMTP id VAA19135 for ; Mon, 2 Feb 1998 21:16:04 -0500 (EST) Received: from TGATE3 (tgate3.mitre.org [129.83.20.27]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with ESMTP id VAA18750 for ; Mon, 2 Feb 1998 21:18:25 -0500 (EST) Received: from mail09.mitre.org (unverified [129.83.20.43]) by tgate3.mitre.org (EMWAC SMTPRS 0.83) with SMTP id ; Mon, 02 Feb 1998 21:18:24 -0500 Received: by mail09.mitre.org; (5.65v3.2/1.1.8.2/22Jun94-0628PM) id AA23020; Mon, 2 Feb 1998 21:18:22 -0500 Received: from tgate3.mitre.org by mail09.mitre.org; (5.65v3.2/1.1.8.2/22Jun94-0628PM) id AA18050; Mon, 2 Feb 1998 21:18:20 -0500 Received: from mbunix.mitre.org (unverified [129.83.20.100]) by tgate3.mitre.org (EMWAC SMTPRS 0.83) with SMTP id ; Mon, 02 Feb 1998 21:18:22 -0500 Received: from VMS.DC.LSOFT.COM (vms.dc.lsoft.com [206.241.12.2]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with ESMTP id VAA18740 for ; Mon, 2 Feb 1998 21:18:22 -0500 (EST) Received: from peach (206.241.12.27) by VMS.DC.LSOFT.COM (LSMTP for OpenVMS v1.1a) with SMTP id <13.E7ECE81D@VMS.DC.LSOFT.COM>; Mon, 2 Feb 1998 21:13:43 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8c) with spool id 42129 for CIFS@DISCUSS.MICROSOFT.COM; Mon, 2 Feb 1998 21:15:42 -0500 Received: from tridge@localhost by samba.anu.edu.au id <12641481-13752>; Tue, 3 Feb 1998 13:04:51 +1100 References: <5CEA8663F24DD111A96100805FFE6587031E3927@red-msg-51.dns.microsoft.com> Message-Id: <19980203020451Z12641481-13752+2368@samba.anu.edu.au> Date: Mon, 2 Feb 98 21:04:45 -0500 Reply-To: CIFS@DISCUSS.MICROSOFT.COM (Common Internet File System) From: tridge@SAMBA.ANU.EDU.AU (Andrew Tridgell) Subject: Re: CIFS auth (was: new CIFS I-D) To: CIFS@DISCUSS.MICROSOFT.COM In-Reply-To: <5CEA8663F24DD111A96100805FFE6587031E3927@red-msg-51.dns.microsoft.com> (message from Paul Leach on Mon, 2 Feb 1998 15:54:35 -0800) X-Mailer: MailWorks 2.0-4