Editor's Note: Minutes received 11/3/92 CURRENT_MEETING_REPORT_ Reported by John Linn/DEC Minutes of the Common Authentication Technology Working Group (CAT) The CAT Working Group met for one session at the November 1992 IETF. Primary discussion topics were: o Status of documents. o Future work items and issues. o Token representation and integration. o FTP security. Status of Documents Steve Crocker stated his belief that the GSS-API and associated C bindings Internet-Drafts were ready for advancement to Proposed Standard RFCs, and that he would recommend this action shortly. The Kerberos V5 Internet-Draft is pending certain local and specific edits, and is to be included in the same advancement recommendation. Despite the fact that Kerberos is the only CAT technology visibly under active development and support at this time, it was still viewed as a desirable goal that applications use CAT/GSS-API rather than mechanism-specific interfaces so as to support future portability. Future Work Items and Issues Ted Ts'o led a discussion suggesting future work items and issues for CAT. He divided client applications for authentication services into four groups: 1. Datagram protocols, generally (e.g., SNMP) not viewed as a good fit for CAT, though better suitability to other connectionless protocols was considered as a possibility. 2. Store-and-forward protocols, also not viewed as a good fit for CAT. 3. Stream protocols (e.g., Telnet, rpc, lpr, NNTP), considered by Ted as the best-fitting candidates for CAT usage. 4. Multiple-stream protocols (e.g., FTP), with suitability not evaluated. His list of thoughts on future work included [with editor's annotations in square brackets]: 1 o A need for better [more complete and fully-tested] GSS-API clients and mechanism implementations, e.g., to implement rlogin with less reliance on local or mechanism-specific routines in addition to GSS-API. o Development of an easy-to-use layer overlaid atop GSS-API to embody token-passing, analogous to Kerberos's krb_sendauth. Ted's list of issues and near-term action recommendations was as follows: o Negotiation of mechanisms: recognized as important in the eventual term, but not needed in the near term, given a presumption that GSS-API callers (in an environment with only a limited number of mechanisms in use) would not be burdened by a requirement to pass in explicit mechanism type specifiers. o Strength ranking of mechanisms: as with negotiation, not needed at first. o Naming: generalized translation between types not needed, but a canonical flat ASCII representation was desirable for ACLs, etc. Internationalization was recognized as an issue here, with a character set selection tag being requested. The long-requested and as-long-frustrated desire for a unifying Internet naming framework also arose as an issue here. o Infrastructure requirements: given that many sites don't want to pay the prices attendant to use of Kerberos, SPX, or similar cryptographic mechanisms, peer-peer key/password exchange and non-disclosing password systems should be considered as CAT mechanisms. An issue here is the fact that such lower-function mechanisms don't generally authenticate principals in terms of global names; use of an interface facility [e.g., a name type tag] to distinguish local from global names is a partial approach to the issue. Many lower-function mechanisms do not yield session keys for per-message protection as a result of authentication, but mechanisms with this characteristic are accommodated with existing interface indicators. Availability of a Kerberos V4 GSS-API implementation would be convenient; while some activities had been undertaken to this end in previous years, no complete implementation compatible with current specifications is known to exist. The GSS-API modules within the Kerberos V5 implementation (as of the re- cent Beta 2 release) have been unit tested, and code exists to support all calls, but have not been linked and tested with a sample client. Ted Ts'o indicated that he would like to coor- dinate with anyone interested in performing this testing, but that he cannot himself provide the resources needed to develop or carry out the tests in the near future; Steve Lunt expressed 2 interest in this activity. Token Representation and Integration The present Kerberos V5 GSS-API implementation includes tagging facilities on its tokens, but (unsurprisingly, given the order of events) the tags do not include the object identifier recently assigned to Kerberos by the IANA and to be included in the upcoming revision to the Kerberos specification. As a goal, it was agreed desirable that applications into which authentication is being newly integrated should use OID-identified mechanism tags. It was noted that use of ASN.1 in tagging should be constrained (and, in the GSS-API appendix's recommendation, is constrained to X.509-DER) so that the use of a fully general ASN.1 parser is not required; further clarification on the encoding conventions and their processing requirements was requested. Ted Ts'o suggested development of a generic ``plug-in'' authentication protocol layered on GSS-API, to be embedded within applications which are built over stream-oriented communications. NNTP was specifically cited as an example; Telnet (given the fact that it acts itself as a sophisticated stream manager and is oriented to transfer of data elements within options) was not considered as a customer for this proposed technology and would be more appropriately served by calling CAT directly. In the ``plug-inx'' approach, a stream would be established by the application and then handed over for use by the authentication protocol while authentication tokens were exchanged. Subsequent to token exchange, within which mechanism negotiation could also be incorporated, the stream could (optionally) either be handed back to the application or the application's communications could be encapsulated and thereby protected by the ``plug-in'' protocol. The ability to reinitiate the ``plug-in'' protocol on an already-authenticated stream, thereby accomplishing reauthentication, was requested in discussion and considered to be supportable. The format of CAT tokens was not perceived as a particularly hard issue from the viewpoint of caller protocols; the prospect the token exchanges in the course of carrying out GSS-API continuation scenarios raises qualitatively different complexity to callers, which use of the ``plug-in'' could simplify. It was observed that existing mechanisms involve exchange of no more than two tokens, one from an initiator to a target and a second returned from the target to the initiator, and that perhaps the most likely scenario in which need for longer exchanges might arise would be design of a ``negotiated'' mechanism in which authentication elements were preceded by tokens transferred in order to establish a mechanism shared between peers. FTP Security At the end of the meeting, Sam Sjogren led a brief discussion on security for FTP, a topic for which he has established a discussion group. Interest exists in Kerberized FTP in order to eliminate transmission of cleartext passwords across networks. The FTP 3 specification states that FTP's control connection ``follows Telnet protocol'', but is silent about use of Telnet options on the control connection and it was believed that at least most FTP implementations would not accept Telnet options on an FTP control port. The FTP specification also states that data elements in FTP commands are usually to be interpreted by humans, but informal communication with Jon Postel suggests that he would not oppose the inclusion of encoded data intended for machine interpretation (e.g., cryptographic authentication tokens) so long as the data elements' contents were properly specified. It was suggested that authentication information for an FTP control connection could be represented either through use of the Telnet authentication option (if Telnet options are found to be supported or easily supportable within FTP) or by direct calls to CAT and textual encoding of CAT tokens. In addition to security on FTP's control connection, there was also interest in protecting the data connection, most efficiently in a block mode. Any such protection would need to be compatible with the variety of transfer modes supported within FTP. Actions Ted Ts'o plans further work on documenting the stream-oriented ``plug-in'' overlay. Neil Haller plans further work on integrating a lower-function authentication mechanism, probably to be based on the S/key technology, under the GSS-API. John Linn plans further work on documenting token encoding conventions and their attendant requirements. Attendees David Conklin conklin@jvnc.net Stephen Crocker crocker@tis.com Cathy Cunningham cmc@microcom.com Art Dertke dertke@gateway.mitre.org William Edison Richard Graveman rfg@ctt.bellcore.com Neil Haller nmh@thumper.bellcore.com Ken Hirata khirata@emulex.com Russell Housley Housley.McLean_CSD@Xerox.Com Frank Kastenholz kasten@ftp.com David Katinsky dmk@rutgers.edu John Kunze jak@violet.berkeley.edu Paul Lambert paul_lambert@email.mot.com John Linn linn@erlang.enet.dec.com Steven Lunt lunt@bellcore.com Mohammad Mirhakkak mmirhakk@mitre.org Clifford Neuman bcn@isi.edu Hilarie Orman ho@cs.arizona.edu 4 Paul Sangster sangster@ans.net Sam Schaen schaen@mitre.org Sam Sjogren sjogren@tgv.com Tang Tang tt@virginia.edu John Vollbrecht jrv@merit.edu Chuck Warlick warlick@theophilis.nsfc.nasa.gov Daniel Woycke woycke@smiley.mitre.org 5