INTERIM_MEETING_REPORT_ Reported by Fred Glover/DEC Minutes of the Trusted Network File Systems Working Group (TNFS) May 1992 Agenda o Reviewed the recent modifications to the TNFS document (TNFS-001.2.02) o Reviewed the TKM document (TNFS-006.01.01) o Reviewed implementation status and issues o Discussed Lock Manager impact o Discussed TNFS auditable events TNFS Document Review The IETF TNFS document has been available for comments in the IETF Draft Directory and TNFS archive since July, 1991. During the May meeting, the Working Group made ``final'' wordsmithing modifications, and edits to the document. This concludes the work planned for the TNFS specification, and the next steps are to transition the document to Proposed Standard. Trusted Systems technology providers are encouraged to commence implementation based upon the current TNFS draft. Final updates to the TNFS document include: o Add vendor specific token to directory response structure, set label procedure arguments. o Change the arguments to the MLD procedure to reference operations rather than flags. o Add explicit indication within ACCESS and file open sections to identify conditions in which a client caching security attributes must revalidate the rights of a given client application (i.e., by calling ACCESS). o Add rationale indicating why security attribute tokens are not required to be included in the read directory response structure. We spent some additional time discussing auditing. Conclusions include: o Some environments may require that both client and server auditing is enabled in order to ensure full audit of events such as: - First read (server audits; may need to check audit id and XID 1 in order to identify actual issuing PID if that is required). - Floating of objects (server only; client can't see). - Server override of privileges (server only; client can't see). o The transaction ID is a possible ``key'' which can be used to correlate a client request with the server side procedure. An updated document will be placed in the IETF and TNFS archives after an ``email'' review of the updates has been completed. In addition, Fred will contact our IETF Area Director, Dave Borman, to understand our ``next steps'' in the standardization process. Token Manager Review The TKM document was also reviewed. It now contains an attribute to token procedure. The following updates will be made to the document: o Editorial (wordsmithing). o Length field added to string arguments. The updated TKM document will be placed into the IETF Draft Directory (informational RFC) and the TSIG TNFS archive. We have been reviewing both the TKM and MAC6 token mapping proposals. Our current recommendation is for each of these to be submitted as IETF informational RFCs. One of these would be identified to become the actual standard, once all of the IETF/TSIG token mapping requirements were understood and were accommodated by at least one of these proposals. We recommended that a new working group be formed which would assume the responsibility of collecting the requirements, reviewing all of the proposals, and making recommendations. Implementation Status, Issues The Working Group reviewed the progress of current implementation efforts. Two implementations are very ``close'' to conformance with the current version of the specification. We discussed testing possibilities for the end of this year. We have already identified a test plan, a set of ``non-mapped'' security attributes for testing, and a modified test routine to be used with the Connectathon test suite. An update of the tnfs.h file, describing all of the TNFS procedures and data structures, will be placed into the TSIG/IETF archive to facilitate development of additional implementations. Lock Manager Update Charlie Watt recently completed a review of the NFS lock manager and suggests that no changes appear to be required to the lock manager to 2 work in the TNFS environment. This confirmed the results of an earlier Working Group discussion and closes an action item. Thanks Charlie! TNFS Auditable Events We started the discussion of TNFS auditable events at this meeting. Mark Saake will be developing a document which describes this area. Conclusions reached at this meeting: o The TNFS Group will focus on server side (i.e., protocol procedure) auditable events; we will expect that POSIX will identify the client side (i.e., application, API based) events and formats. o When the server receives a TNFS request, it can identify: - Host address (and thus host) - File handle - Export structure - Procedure number - Version number - Credential information (ID info); result of subsequent authorization check (i.e., pass or fail). - Log entry and exit status of each called TNFS server procedure. Next Meeting The TNFS Group will plan to meet jointly with IETF and TSIG at the July meeting in Boston. At that meeting, we plan to: o Present a summary to interested IETF attendees during a designated two hour time slot. o Review the ``final'' version of the TNFS documents (updated documents placed into the TNFS archive and IETF Drafts Directory: Fred, Fran, Carl, Ali). o Review the interoperability test opportunities, plans (all). o Review NFS test suite extension for TNFS (Fran). o Identify conforming implementations to support our request to transition our TNFS document (all). o Review identification of auditable TNFS events (Mark). o Place ``tnfs.h'', test plan, test attributes into TNFS archive (Fred). 3 The July meeting is planned for the 13th-17th at the Hyatt Regency in Cambridge, Massachusettes. Attendees Lida Carrier lida@apple.com Fran Fadden fran@decvax.dec.com Jonathon Fraser Fred Glover fglover@zk3.dec.com Ali Gohshan Brian Hardy Mark Saake saake@netcom.netcom.com Carl Smith cs@eng.sun.com T.T. Tao Charles Watt watt@sware.com 4