CURRENT_MEETING_REPORT_ Reported by John Linn/Geer Zolot Associates and Sam Sjogren/TGV Minutes of the Common Authentication Technology Working Group (CAT) The Common Authentication Technology Working Group (CAT) met for two sessions at the Columbus IETF. The primary Agenda item was integration of security features into FTP, a topic for which Sam Sjogren is acting as task leader and on which Steve Lunt has generated a working document which will shortly be released as an Internet-Draft. Additional discussion topics were the advancement status of currently active CAT Internet-Drafts (GSS-API, GSS-API C bindings, and Kerberos V5), and a working proposal by Ted Ts'o for a CATS stream-oriented protocol overlay to be used in conjunction with GSS-API. Status Of Specifications The CAT Internet-Drafts have been pending administrative action for some time, and an action plan was evolved for their advancement recommendation. An updated Kerberos V5 specification was produced by Cliff Neuman; comments received from its review list by April 10th will be reflected in an Internet-Draft to be issued by April 17th. Primary late-breaking changes include added detail on an encrypted timestamp preauthentication type, and a new message type for credential exchange when proxies are being provided to an end server. Concurrently with the Kerberos specification review, an advancement memo will be prepared for the set of Internet-Drafts (GSS-API, GSS-API C bindings, Kerberos V5). Intended follow-on documents will include a CAT mechanism definition (with token format) based on Kerberos V5. It was determined that use of the mechanism tagging recommended in GSS-API Appendix B should be adopted as mandatory, and message stream facilities were strongly desired within GSS-API mechanisms in order to satisfy FTP functional and integration requirements; a new appendix to the GSS-API specification has been drafted and distributed to the CAT mailing list codifying the results of this discussion. CATS Stream Protocol The CATS proposal, presented by Ted Ts'o, was engendered by a desire to provide prospective protocol integrators with a subprotocol specification for security, along with a stream-oriented API. An explicit CATS goal is that it be implementable quickly and without kernel modifications (unlike, e.g., IP- level security). CATS presents an alternative, generic form for protocol integration, contrasting with the protocol-specific integration being employed in Telnet options and FTP commands. Submission of a revised CATS specification as an Internet-Draft is planned. In evolving CATS, Ted observed that the status of the tagging scheme in GSS- API Appendix B as a recommendation to mechanism designers led to 1 undesirable ambiguity, and suggested making it mandatory; this suggestion was adopted and would be integrated into the Kerberos V5 implementation. Among other discussion, it was suggested that the CATS protocol be extended in order to exchange preamble tokens in advance of context establishment for mechanism type negotiation, and this prospect will be examined. FTP Security Sam Sjogren began the FTP part of the meeting by describing the goals for the FTP security work, as initiated at a BOF during the previous IETF and to be continued under the CAT Working Group framework. Support for authentication, as well as integrity verification and privacy, via any of a number of different mechanisms will be provided by this work. Steve Lunt presented his proposal for extensions to the FTP protocol (additional commands) to implement the security goals; he intends to make an FTP security implementation publicly available. An overhead presentation supplemented the draft that had previously been posted to the Group's mailing list. Lively discussion occurred during and after this presentation, to the point that an additional evening meeting was scheduled to continue the discussions. The resulting FTP security discussions were quite fruitful, both in terms of providing feedback for improving the draft proposal for FTP as well as fine tuning the GSS-API requirements and specifications. It was decided that the case of a three-party FTP interaction is sufficiently complex and rarely enough used that specification of how to do it securely will be deferred, probably to a separate document to be produced later. Once peer entity authentication has been completed (and a session key is available), the proposed FTP security approach protects all subsequent FTP commands for at least integrity (encapsulation of base-64 encoding of gss_seal() output within MIC command), and optionally for confidentiality as well as integrity (encapsulation within ENC command, gss_seal() conf_flag TRUE). It was observed that underlying GSS-API mechanisms must represent and protect the conf_avail flag value and other service availability indicators within their tokens to prevent active attacks; the to-be-written ``Kerberos Vn for GSS-API'' and other mechanism design documents will describe how this protection is provided. (These indicator protection requirements apply independently of whether GSS-API is employed.) To protect against active attackers corrupting a data or control stream by changing the order of data or commands in the stream, protection via sequence numbers or some other such technique must be provided by the FTP security standard or the underlying mechanisms. Given that the FTP control connection is a Telnet stream, questions arose about the rationale for not using the Telnet authentication option as an approach for FTP. Steve cited two reasons: (1) because the Host Requirements RFC precludes use of Telnet options on the FTP control connection, and (2) because of a desire to provide data integrity, which Telnet security does not offer. 2 There was discussion of the fact that no facility was exposed at the level of the FTP security commands for negotiating the type and strength of cryptography to be used for data protection. However, it was recognized that such features can exist within underlying mechanisms yet remain transparent at the level of FTP. The ordering of USER and AUTH commands will be made such that an FTP server may make a decision on what authentication and encryption mechanisms are acceptable based on who the user is. Kerberos ticket granularity and naming issues were discussed. For Kerberos V4, the form of a target FTP server's name should be ``ftp.'', and for Kerberos V5, ``ftp/''. It was noted that use of different target names for different server processes within a host is not primarily an access control measure, but does permit the servers to run in different protection domains (as might be desirable for an FTP server available to casual remote users). Areas to be revised in the FTP draft based on discussion include: o Additional discussion of requirements. o Approach for transfer of arbitrarily long tokens from client to server. o Alignment of base-64 encoding technique with RFC1421. o Statements regarding mechanism negotiation (including a statement that an FTP server may refuse to accept anything less than suitably strong authentication). o Further work on the data stream protection approach. Attendees Steve Alexander stevea@lachman.com John Campbell jrcamp@nosc.mil William Chung whchung@watson.ibm.com Stephen Crocker crocker@tis.com Dave Cullerot cullerot@ctron.com Antonio Fernandez afa@thumper.bellcore.com James Galvin galvin@tis.com Jisoo Geiter geiter@mitre.org Richard Graveman rfg@ctt.bellcore.com Frank Kastenholz kasten@ftp.com David Katinsky dmk@pilot.njin.net Charles Kaufman kaufman@zk3.dec.com Stephen Kent kent@bbn.com Zbigniew Kielczewski zbig@eicon.qc.ca Andrew Knutsen andrewk@sco.com 3 Paul Lambert paul_lambert@email.mot.com John Linn linn@gza.com James Mahon mahonj@honfsi1.att.com Cynthia Martin martin@spica.disa.mil Evan McGinnis bem@3com.com P.V. McMahon p.v.mcmahon@rea0803.wins.icl.co.uk Bob Morgan morgan@networking.stanford.edu Clifford Neuman bcn@isi.edu Emmanuel Pasetes ekp@enlil.premenos.sf.ca.us Christopher Provenzano proven@csi.compuserve.com Steven Richardson sjr@merit.edu April Richstein amr@tycho.ncsc.mil Shawn Routhier sar@epilogue.com Jeffrey Schiller jis@mit.edu Wolfgang Schneider schneider@gmd.de Sam Sjogren sjogren@tgv.com Stuart Stanley stuarts@apertus.com Bob Stewart rlstewart@eng.xyplex.com Stuart Stubblebine stubblebine@isi.edu Louisa Thomson louisa@whitney.hac.com Klaus Truoel truoel@gmd.de Theodore Ts'o tytso@mit.edu James Weatherford weatherf@nosc.mil Peter Wilson peter_wilson@3com.com 4