IFS TIG #1 - Feb 5, 2001 / 1:00pm - 2:25pm Present: Kevin Rowland, Zuwei Liu, Paul Go, Chris Fruehwirth, Joseph Franco, Katie English, Velma Harris, Jeff Morgan, Gary Dobbins, Ian Byrne, David Yeh, David Klawiter * Difference between Stakeholders and TIG (Technical Interest Group) * Two architectures providing file service to all platforms * Authentication/Authorization in two Realms * Two ways of serving CIFS - - - - - - - - - - - - - - - - - - - - - - - - - - - * Difference between Stakeholders and TIG (Technical Interest Group) - - - - - - - - - - - - - - - - - - - - - - - - - - - Kevin began the meeting by explaining the purpose of two groups created to work on the IFS project. The stakeholders group was responsible for determining what the needs are and if options presented by the project team satisfied those needs. The TIG's purpose is to propose design options that deliver the services that the stakeholders group defines. - - - - - - - - - - - - - - - - - - - - - - - - - - - * Two architectures providing file service to all platforms - - - - - - - - - - - - - - - - - - - - - - - - - - - The original idea for IFS was to have a single file space that would serve all platforms. It quickly became apparent that no single mainstream technology could provide such a global solution adequately. Only one such product had ever come close to accomplishing this (DCE/DFS) and has never achieved wide acceptance. The only practical approach is a multi-platform architecture. Components of a multi-platform architecture: 1. AFS stays in place (PC/Mac access is accomplished by the current means) 2. A CIFS-based file system is developed to better accommodate the needs of the PC and Mac platforms. A question posed was where CIFS was purchased from (specifically, "What company sells CIFS?"). CIFS is not a product, but a protocol specification. It is the defacto standard for communications with Microsoft products. It is also a practical solution for Macs, which have similar requirements (ie: stateful server connection, record/file-locking). The TIG must define the specifics of the CIFS file server / space. 3. Bridging between the file systems is impractical as no product is available to efficiently communicate between the two file systems. Access must be accomplished at the client. The above points were accepted and ratified by the TIG. - - - - - - - - - - - - - - - - - - - - - - - - - - - * Authentication/Authorization in two Realms - - - - - - - - - - - - - - - - - - - - - - - - - - - With two separate file systems, each with differing implementations of Kerberos, it is necessary to have parallel methods for authentication and authorization. An MIT KDC will drive the authentication for both file systems. A W2K-based, CIFS file system must remain in the W2K realm because Microsoft has implemented the authorization fields in the K5 specification. With this, any MS-K5 aware client can take advantage of Active Directory authentication/authorization methods. Cross-realm authentication is accomplished via a one-way tranisitive trust with the W2K realm trusting the MIT realm. W2K (Windows 2000) ACLs are very similar to AFS and includes user-created groups. For other clients to access the CIFS-based file system, NTLMv2 is used to initiate communication directly with the CIFS file system which operates on a pass-through authentication. The caveat here is that the passwords in the two realms must be synchronized. While this synchronization could be accomplished individually on each system, it could also be done via a web page where the user could affect a password change to both realms. (This issue really falls under the purview of the stakeholders group as a functional requirement.) - - - - - - - - - - - - - - - - - - - - - - - - - - - * Two ways of serving CIFS - - - - - - - - - - - - - - - - - - - - - - - - - - - 1. W2K: Direct Attached Storage (SAN) 2. Network Attached Storage (NAS) Using W2K as a front-end to a direct attached storage system provides the integration of Kerberos5 for clients that are MS-K5 aware. None of the available NAS solutions support Kerberos although some have stated that they will have K5 implemented by Q3 -2001. The meeting was adjuorned at 2:25, going longer than it was scheduled. We will try to schedule another meeting for later this week to continue with the discussion.