Network Computingwww.networkcomputing.com

Major players include not only Sun, but also industrial-strength, high-availability server heavyweights such as Auspex Systems, Falcon Systems and Network Appliance Corp.

However, by making the specification for CIFS openly available, Microsoft may make up the distance quickly. The Santa Cruz Operation (SCO) and Network Appliance, among others, already offer a commercial CIFS server product.

· User Authentication Security is not a concern if your goal is open, public, read-only volumes like a modern-day replacement for an anonymous FTP site. However, when opening your file server so that you have read/write access to corporate files via the Internet, you would expect security to be well-thought-out in the WebNFS and CIFS protocols. Unfortunately, it isn't. WebNFS and CIFS let administrators define who can read/write what, but the catch involves authenticating incoming people securely.

Apparently, the authentication challenge is too great for WebNFS; like NFS, it leaves the process of user authentication to someone else. On most sites, this someone else is the "pcnfsd" protocol, NIS, NIS+ or some other authentication method. The NFS protocol has no notion of passwords. You can control which hosts the server speaks to based on IP address. Nevertheless, the lack of an authentication mechanism in the NFS protocol itself gives rise to the popular NFS rule of "export volumes only to trusted hosts."

Hopefully, you have a static IP address on the Internet and nobody launches an IP spoofing attack. Leaving the authentica tion mechanism out of WebNFS may not be a bad design philosophy, but it presents a problem until some general and widely available solution, such as Secure Sockets Layer (SSL), IP Security (IPsec) or Kerberos is integrated. To address this concern, Sun expects to integrate Kerberos authentication into its own NFS implementations next year.

CIFS, on the other hand, offers a widely implemented, integrated, rich authentication mechanism. Unfortunately, it sacrifices security to retain backward compatibility. CIFS authenticates via a fairly sophisticated challenge-response mechanism with encrypted-only passwords being sent over the network.

But earlier implementations (prior to Windows NT) cannot handle this sophisticated mechanism. If the server or client side claims to be ignorant, CIFS removes any extra measure of security gained via this mechanism by requiring the client to send and the server to accept plain-text, nonchallenged passwords. This requirement leaves CIFS vulnerable to brute-force and "ma n-in-the-middle" attacks. NetBIOS name services and the "Network Neighborhood" browsing scheme are also security worries, since they can be coaxed to divulge relevant host name and user name information to intruders.

To Microsoft's credit, several security patches have been released to thwart some specific attacks. Additionally, the latest revision of the CIFS specification fixes some of the holes created by backward compatibility (though few implementation patches were available at press time). Despite these improvements, it took us just 10 minutes of browsing to locate a popular hacker Web site containing a well-written, hands-on 34-page document with recipes for launching attacks against CIFS. For now, you should use a virtual private network (VPN) or similar encryption solution with WebNFS or CIFS when exporting volumes with private data over the Internet.

· Stateless or Not? WebNFS servers are stateless, so they are not required to store any persistent information about what their clients are doing; all state information in WebNFS (and NFS) is the client's business. Advocates for state in the server argue it bestows good fault tolerance and less complicated server failover schemes. If the server crashes and then reboots, clients simply continue where they left off. CIFS servers, on the other hand, are not stateless. Given the previous instance, clients may not resume normal activity because some data, or state, regarding a client's connection status kept by the server could be lost.

Advocates for a state server model counter that it lets the server pursue a more aggressive caching and buffering policy (enhancing performance), as well as safer file locking and synchronization. In WebNFS, all file locks are advisory while in CIFS, file locks are enforced.

· Market Games Unfortunately, there are few lucky souls who can make IT decisions based on the quality of the technology alone. With that in mind, we offer the following comparison of market impregnation strategies. Microsoft's main weapon in this area is obvious and compelling: CIFS is free as part of the Windows operating system.

Even though Sun is dropping the list price of PC-NFS to $79 per client (quantity discounts would make it even less), budget managers at shops with Windows clients instantly have 79 reasons per client why they should use CIFS.

Of course, CIFS is far less interesting for organizations with significant numbers of non-Windows machines, since there are very few non-Windows CIFS clients. But Microsoft's list of vendors that are joining the CIFS bandwagon is impressive, and CIFS is slated to be the de facto file system for the forthcoming Intel-Microsoft Network PC standard.

Likewise, WebNFS is marked as the probable standard for Oracle and Sun's vision of network computers (NCs). Sun has a strong partner on the browser front, thanks to Netscape Communications Corp.'s commitment to WebNFS. Although Sun has a huge list of vendors representing platforms that support NFS, many NFS-partner vendors are stuck at NFS version 2. Sun has not been as successful at getting other vendors to support NFS version 3, and even less successful with universal vendor acceptance of certain peripheral NFS technologies, such as CacheFS. It remains to be seen how many WebNFS-compliant offerings will be available a year from now. One major advantage is Sun's controlling influence over the fate of Java. When the time comes for a standard Java network file system class, all bets will be on WebNFS.

Todd Tannenbaum is lead developer for the Condor project at the University of Wisconsin-Madison and the president of Coffee Computing Corp., a networking software developer. He can be reached at ttannenbaum@nwc.com.