CURRENT_MEETING_REPORT_ Reported by John Linn/Geer Zolot Associates and Sam Sjogren/TGV Minutes of the Common Authentication Technology Working Group (CAT) The CAT Working Group met for two sessions at the Amsterdam IETF, discussing (in about equal proportion) general CAT issues and FTP security integration. Review of CAT Activities We reviewed the status of CAT-related Internet-Drafts: ``Generic Security Service Application Program Interface'' (GSS-API) and ``Generic Security Service API : C-bindings'' are in the hands of the RFC Editor pending advancement to Proposed Standard status, as is ``The Kerberos Network Authentication Service (V5).'' The Kerberos V5 GSS-API implementation has not received recent development effort, and is not currently compliant, but a plan to make volunteer resources available is being explored. Chuck McManis discussed CAT-related activities ongoing at Sun Microsystems. Sun currently supports Kerberos V4, and plans to migrate to V5. Kerberos is invoked (using its native interface, rather than GSS-API) from RPC. Separate work on layering RPC atop GSS-API had been ongoing at Sun, but has not yet yielded conclusive results. One of the US National Laboratories had ported beta 2 of Kerberos V5 to Solaris, and Sun is working with the resultant code base. CAT Technical Discussion Two proposals for incremental changes to the GSS-API documents were considered: 1. A terminology change in response to a request from X/Open, renaming the per-message protection primitives from GSS_Sign to GSS_GetMIC, GSS_Seal to GSS_Wrap, GSS_Verify to GSS_VerifyMIC, and GSS_Unseal to GSS_Unwrap (to avoid conflict with other usage, without change to function, preserving (though deprecating use of) existing names in existing code for backward compatibility) was tentatively accepted pending e-mail review. In evaluating the request and considering alternatives, it was observed that ISO's usage of the term ``seal'' echoes the notion of applying a wax seal to a document. It was also observed that the current Kerberos V5 implementation of GSS_Sign emits a token containing the entirety of the input message rather than just a signature. 1 It was also observed that no GSS-API per-message protection interface currently exists to provide confidentiality without integrity, and post-meeting review (GSS-API specification, Section 1.2.2) confirmed the related point that mechanisms indicating the availability of per-message confidentiality services are also expected to indicate and offer per-message integrity. No definitive conclusion was reached about the level of demand for confidentiality without integrity. 2. A proposal to add GSS_set_default_cred and GSS_lookup_default_cred routines was rejected for reasons of semantics which were considered to be environment-specific (though considered as a likely initial entry in a set of extensions for POSIX and like environments). Much of the motivation for this feature derives from a desire to control the set of credentials which will be transferred by inheritance across the UNIX fork operation. It was observed that it would be difficult to implement the set_default_cred function within the current Kerberos V5 code base, and that different implementors could implement the proposal as defined with conflicting semantics which would not support application portability. Given an observation that credentials structures are ephemeral, use of acquire_cred with (non-ephemeral) principal names as arguments was recommended as an alternative approach which would survive UNIX forks. Chuck McManis expressed interest in using set_default_cred as a means to spawn threads using different mechanisms for different threads, and saw this as a more critical priority than use of different identities within a single mechanism; he also expressed a desire that credentials be ``lightweight'' structures. CAT Follow-On Tasks and Action Items Follow-on tasks identified were: o Kerberos V5 GSS-API mechanism specification and code enhancement; o Kerberos V4 GSS-API implementation; o ``negotiated'' mechanism definition (a task to which a framework discussion authored by Bob Blakely and forwarded to the list was considered relevant); o CATS stream-oriented overlay definition; o documentation of mechanism implementor's guidance/agreements; and 2 o environment-specific specifications and extensions (e.g., credential inheritance semantics). Individuals and subset groups were associated with several of these items. Activity on the ``negotiated'' mechanism's design was argued as not being critical at this time; it will assume greater importance once multiple mechanisms are actively supported. FTP Security The discussion on FTP security was moderated by, and this section of the minutes was reported by, Sam Sjogren. Review of FTP Activities Discussions on the CAT mailing list as well as at the Columbus IETF meeting in March resulted in changes to the specification for security in FTP. Steve Lunt revised the ``FTP Security Extensions'' Internet-Draft and submitted it to the IETF Secretariat for announcement. A list of changes made to the document was also produced and was sent to the CAT mailing list. Since Steve was not able to physically attend the group's meeting in Amsterdam, arrangements were made to allow Steve to participate via speakerphone. The list of changes was the focus of most of the group's discussions. FTP Technical Discussion One of the additions to the FTP security document is a specification using the GSS-API authentication type. This specification needs to be reviewed in detail and any problems corrected. John Linn will communicate his observations to Steve on this. Although the interaction of the AUTH, PASS, and USER commands have been clarified somewhat, it was agreed that the various possible cases (including those involving users for whom passwords (which should be protected) may be required in addition to other forms of authentication) should be more rigorous. The form of Base-64 encoding used by FTP security has been brought into line with that used by PEM. One concern is that the length of a Base-64 string is currently unbounded, and that may cause problems for small-machine implementations. This will be addressed in the small-machine discussion on the mailing list. For the time being, proxy file transfers are deferred. One of the effects of this is that the requirements for negotiating session keys are eased. However, the negotiating of session keys with the various 3 possible mechanisms should still be investigated to make sure that in the future we will not be precluded from supporting this feature. It is necessary for a server to indicate to a client, somehow, what levels of security are supported (e.g., integrity but not encryption). Although this has been left purely to the particular mechanism, there is a feeling that the protocol itself should provide some support for determination of this when mechanisms themselves do not support it. So, a 402 reply code is defined which indicates to a client that ENC and/or MIC commands are not accepted, thereby allowing a client to probe a server to determine the levels of security it supports. Note that this even allows a server to force the use of privacy but not allow mere integrity assurance. This method is authentication-mechanism independent. In the case of a server allowing integrity but not privacy, implementors are encouraged to warn the user that the level of security available is less than they have requested. Another potential small-machine issue surfaced in the specification of buffer size and length for protected file transfers. Although the length field in the specification has been reduced from 4 bytes to 2 bytes, thereby reducing the buffer size from 4 gigabytes to 64 kilobytes, even a 64-kilobyte buffer may prove to be a problem for some small machines. This issue will be discussed further on the mailing list. Instead of the commonly used `rcmd' principal that is usually used with Kerberized TELNET and R-Utilities, the principal name `ftp' has been specified for use with FTP security. There was a feeling that a number of sites may wish to avoid the additional overhead of creating another principal for each machine, so there should be some capability to fallback to use of the `rcmd' principal. This would appear to be an issue left to particular implementations and site policy. Perhaps it should be mentioned in the Internet-Draft that clients are recommended to first try the `ftp' principal and if the `ftp' principal does not exist or the FTP server will not accept the `ftp' principal, then try the `rcmd' principal. Various other small changes were made to the Internet-Draft that were either corrections or clarifications and are not worth mentioning in the minutes. FTP Follow-On Tasks and Action Items There will be discussion on the CAT Working Group mailing list regarding the buffer size issues and how a small-system implementation may be affected by large buffers or buffers of indefinite size. Steve will incorporate the changes that arose from the group's discussions into the Internet-Draft and produce a new revision of the document and a list of changes. 4 The most important thing to do at this stage is to gain more implementation experience. Sam will solicit implementors through various e-mail lists and other channels. Attendees Matti Aarnio mea@nic.nordu.net David Arneson arneson@ctron.com Stefan Braun smb@cs.tu-berlin.de Richard Graveman rfg@ctt.bellcore.com Neil Haller nmh@thumper.bellcore.com Thomas Hutton hutton@opus.sdsc.edu John Johnston john@berlioz.nsc.com Nada Kapidzic nadak@dsv.su.se John Larson jlarson@parc.xerox.com Arjen Lenstra lenstra@bellcore.com John Linn linn@gza.com Kim Chr. Madsen kimcm@ic.dk Chuck McManis chuck.mcmanis@eng.sun.com Clifford Neuman bcn@isi.edu John Penners jpenners@advtech.uswest.com Robert Reschly reschly@brl.mil Jeffrey Schiller jis@mit.edu Wolfgang Schneider schneiw@darmstadt.gmd.de Sam Sjogren sjogren@tgv.com Theodore Ts'o tytso@mit.edu Erik Zegwaart zegwaart@surfnet.nl James Zmuda zmuda@mls.hac.com 5