CURRENT_MEETING_REPORT_ Reported by John Linn/OpenVision and Sam Sjogren/TGV Minutes of the Common Authentication Technology Working Group (CAT) Brief Summary The status of ongoing GSS-API and application development and testing was reviewed: there are now two independent Kerberos V5 GSS-API implementations, and minor alignments to match ``The Kerberos Version 5 GSS-API Mechanism'' (draft-ietf-cat-kerb5gss-00.txt) are expected to enable verified interoperability. Various demonstration applications, rlogin, and a security layer under Sun RPC have been implemented with GSS-API; we need to proliferate one or more of these applications, and/or GSS-API-based FTP security, in order to validate interoperability and in preparation for advancing RFCs 1508-1510 to Draft Standard status. Steve Crocker suggested that draft-ietf-cat-kerb5gss-00.txt should reach Proposed Standard level and be considered for advancement along with RFCs 1508-1510, but that the application(s) used to exercise GSS-API functions would not also be required to be at Proposed Standard level. John Linn reported on the X/Open preliminary specification containing the technical content of RFCs 1508 and 1509. Sam Sjogren led FTP discussions. Results gained from the FTP Security virtual bakeoff in March were limited, and Sam solicited more implementations for a follow-up event in June; several individuals responded. Steve Lunt's Kerberos V4 FTP security implementation at Bellcore has been ported to several platforms and is available by anonymous FTP. The group believes that the FTP Security Internet-Draft is ready for advancement to Proposed Standard. Several GSS-API technical topics were discussed as inputs to future document revisions, including: continuation facility for protection of large messages (proposals being discussed by e-mail), incremental building of credentials for multiple mechanisms (tabled for consideration as part of broader multi-mechanism support issues), confirmed context close facility (not adopted), features for efficient protection of character-at-a-time protocols (modelable as QOP), ability to operate in a non-blocking fashion (considered OS-specific, possibly a candidate for different environment bindings), and a number of more detailed points. Status of Public-Key Activities Steve Crocker recalled the fact that a public-key GSS-API mechanism had once been under development, and that work to integrate Kerberos and public-key technologies into a common mechanism had once been underway, and inquired as to whether there was any recent status in these areas. No recent development is known, although a comprehensive design for a public-key mechanism remains available in (Experimental) RFC 1507. It was reported that work on development of a V6 Kerberos, incorporating public-key cryptography, was underway, but no detailed report was available. Implementation Status Report Two Kerberos V5 GSS-API implementations now exist, one developed at Digital and the other at OpenVision; the latter implementation's GSS-API code is also incorporated in MIT Kerberos V5 Beta 3. Internet-Draft draft-ietf-cat-kerb5gss-00.txt defines the token formats needed for interoperability; minor changes to the OV code will be made to align with the specification, after which interoperability will be verified. Trial sample applications (e.g., a secured echo function) have been written; further productive applications (e.g., FTP security over GSS-API) need to be developed. It was also reported that IBM has an implementation of GSS-API available as a product and built atop KryptoKnight technology. Late in the meeting, it was noted that SESAME has implemented a version of rlogin secured with GSS-API, and that this might be made available for use as a testing vehicle. Status of Specifications John Linn presented an overview of the recently-released Kerberos V5 mechanism Internet-Draft, draft-ietf-cat-kerb5gss.txt. A comment was made that this draft, along with RFCs 1508-1510, was insufficient to enable an independent implementation, but no data was available about the areas of perceived insufficiency; further comments were solicited on the mailing list. An X/Open preliminary specification containing the technical content of RFCs 1508 and 1509 has been published. One comment made, in a likely future directions appendix, suggested that text be added to underscore the feasibility of mechanisms or usage modes in which no authentication need be performed at context establishment time, although per-message protection would be fully supported. The group agreed that it was appropriate to add such text. We discussed the steps needed to advance RFCs 1508-1510 from Proposed Standard to Draft Standard level. The layered interrelationship among these documents, and the technologies they describe, implies that several specifications' content must be implemented and integrated before we can demonstrate interoperability; we need GSS-API implementations as well as applications to exercise their functions. Steve Crocker proposed that we should demonstrate and advance the content of 1508-1510 and the Kerberos V5 GSS-API Internet-Draft together, implying that the Internet-Draft first be advanced to Proposed Standard, but that the calling application layered above GSS-API need not itself be at the Proposed Standard level. Since 1508-1510 have been at Proposed for about six months, they have another 18 months within the official window for advancement to Draft Standard. FTP Security During the CAT Working Group's session on Tuesday 29 March 1994, there was discussion of the FTP Security section's work. Sam Sjogren led this part of the meeting. The main focus of the work is the FTP Security Internet draft authored by Steve Lunt. At the previous CAT meeting, at the IETF meeting in Houston, a ``virtual bakeoff'' for interoperability testing of implementations of the FTP Security specification was proposed. This bakeoff was intended to be virtual in the sense of happening over the Internet instead of in a single physical location. With it being a scheduled event, it would hopefully help people get work done by giving them a deadline to work toward. It has been observed that often most work for IETF gets done right before meetings, so perhaps providing more ``events'' will result in more work getting done. It was agreed that the virtual bakeoff was a good idea and so one was scheduled for the week of 14 March 1994. The advantages of virtual bakeoffs are that they don't require a physical presence by the bakers, they are easy to reschedule, are inherently flexible overall, are done over the Internet, and easily accommodate travel schedules. Unfortunately, these same potential advantages can also be disadvantages, and contributed to the relatively low level of success of the event. There was a very low level of participation. Travel and other work took precedence when the time came; it was clear that an event with a low cost of participation is too easy to pull people away from. Since the event was scheduled only two weeks before the Seattle IETF meeting, there wasn't much time available after the scheduled bakeoff week to use the inherent flexibility of the event to follow up on the week's experiences. However, some porting experience with Steve's code was obtained and it is hoped that the next virtual bakeoff will be much more successful. The next virtual bakeoff is scheduled for the week of 27 June 1994 (a month before the Toronto IETF meeting), and Sam will do more arm-twisting to get other implementors to participate. One of the features of the FTP Security specification is the support of challenge/response mechanisms for one-time passwords. This would allow use of S/Key or various types of hand-held authentication devices. As long as an FTP client shows the user the full contents of the responses received from the server and allows the user to type arbitrary FTP commands (e.g., via the QUOT command that many FTP clients support), then even an ``insecure'' FTP client could be used with a one-time password system to avoid sending cleartext passwords across networks. It may not even be necessary to send arbitrary commands to the FTP server if, due to general policy or depending on the origin of the FTP connection, the server assumes ``one-time-password mode'' and sends a challenge in response to the USER command as received from the client and then the response is sent by the user in the PASS command instead of their real password. Unfortunately, ``smart'' or ``friendly'' FTP clients exist, which do not show the user all the responses from the FTP server nor allow the user to send arbitrary commands to the server. In particular, masking of the USER command by client implementations complicates integration of one-time password schemes. [Note: Integration of systems like SecurID and S/Key does not require client modification or use of QQUOTE commands since the challenge is one-way; changes are confined to the server side.] The question was posed to the group as to whether anyone could think of any way to deal with such clients, perhaps through some sort of out-of-band pre-authentication mechanism. No one had any ideas about how to deal with such a client, although it was suggested that such clients usually have some way to enable a debugging mode to show the responses received from the server. Any other suggestions or observations along these lines would be most welcome on this open problem. At this point we have rough consensus and some running code. In addition to Steve Lunt's Kerberos V4 implementation, which has been ported to several platforms, it was reported that Prem Tirilok is working on FTP security with Kerberos V5. We have decided to recommend that the FTP Security draft be advanced, in its current state, to Proposed Standard status. There was some question over whether the appendices, which specify the Kerberos V4 and GSS-API mechanisms, should be included in the advanced document, especially since there does not yet exist an implementation of the GSS-API mechanism for FTP. There seems to be no problem advancing the draft in this state to Proposed Standard, as either or both appendices can be removed from the document at the time it is proposed for further advancement. We hope that once the draft becomes a Proposed Standard it will attract more attention in the form of independent implementations. CAT Technical Issues 1. Asynchronous, Non-Blocking Support This topic concerns the idea of providing support in V2 for asynchronous, non-blocking operation. It was considered an OS-specific issue, possibly a candidate for different sets of environment bindings and/or use of separate, environment-specific, libraries enabling support for asynchrony. Further discussion on the mailing list was solicited. Ted Ts'o raised the topic, following some discussions he had had with Kerberos developers working on a Macintosh platform. As a premise, Macintosh driver calls must be non-blocking to avoid locking the system as a whole. Commonly, this is achieved by passing the Macintosh kernel a pointer to a callback function to be invoked when a packet is received. GSS-API evolved in a UNIX environment, where other means (e.g., select, multi-threading) to support asynchrony are commonly available, but no such facilities can be assumed in the Mac world or in various other non-UNIX environments (e.g., Windows?). The X-Windows system uses an OS-specific select call within its implementation to respond to this issue. Piers McMahon (ICL) noted that GSS-API's present synchronous behavior works well in a multi-threaded environment, that it was preferable for callers in such an environment, and that callbacks can't be generalized. Steve Lunt noted that support for asynchrony was properly the job of an implementor within a particular environment. Generally, we observed that issues of support for asynchrony are quite OS-specific, and are not specific to implementation of security versus other services on the same platforms. 2. Large Messages This issue concerns a desire for a continuation facility on per-message calls so that an entire, possibly-large, buffer doesn't have to be passed in and processed in a single ``gulp,'' and so that a single integrity check can enclose the entirety of such a large message. Such a facility could be implemented either in a manner similar to the CONTINUE_NEEDED facility used for context establishment, or through callbacks. Proposals were presented at the meeting (by John Linn) and by e-mail (by Steve Lunt); discussion is ongoing on the mailing list. About half of the meeting's attendees believed that we should proceed with a means to support a continuation facility in V2. Steve Lunt noted that his proposal would eliminate the need for the size negotiation facility currently built into the FTP Security Internet-Draft. Several aspects of the issue are noteworthy: the local issue of a caller wishing to protect a message greater than the local size limit, the distributed issue of a caller at an endpoint with a larger buffer size sending a protected message to another endpoint whose maximum size is smaller, the potential inefficiency of declaring and preallocating a fixed-size buffer rather than applying dynamic (though unpredictable) allocation when needed, and mechanisms' placement of checksums at the beginning versus at the end of a token. It was agreed that, minimally, GSS-API should provide callers with a facility which enables them to determine a safely-small size buffer processable locally. This could be accomplished with a new INQUIRE_SIZE primitive, as new outputs from INIT_SEC_CONTEXT and ACCEPT_SEC_CONTEXT, and/or as a new output from INQUIRE_CONTEXT. The next level of function, indicating a safe buffer size processable by both peers to a context, was discussed but consensus was not reached at the meeting and discussion was remanded to the mailing list. It was noted that the maximum size could likely be mechanism-specific, and there was controversy within the group as to whether size negotiation should be performed within GSS-API and its mechanisms. Clearly, GSS-API cannot and should not handle the fully general problem of message segmentation between applications; it's likely, however, appropriate to inform callers of size limits imposed by the security service implementation in order that the callers may factor those limits into their processing or negotiation. It was observed that application-visible size issues would not arise if, as in DNSIX, security features were embedded below the application layer. Following a discussion with Warwick Ford, John Linn summarized this proposal: provide a ``continue'' versus ``final'' flag to be used as an input to Sign and Seal. Elements of a continuation message must be presented in order, and no other messages may be interspersed on a context while a continuation message is being processed; applications (likely in conspiracy with their underlying transports) are responsible for providing ordered, complete delivery of elements to Verify and Unseal, which would report errors if misordered or missing elements were detected. Verify and Unseal would return CONTINUE_NEEDED status after processing non-final tokens; integrity check would not be valid except when final token is processed. Context establishment tokens should declare a guaranteed buffer size to a peer, which could be retrieved through INQUIRE_CONTEXT; a new GSS_TOKEN_TOO_BIG MAJOR_STATUS value seems warranted. 3. Iteratively Appending Credentials This topic relates to a suggested ADD_CRED facility, which would be used to append credential elements, associated with a different mechanism, to a different credential set. Iterative use of ADD_CRED would enable unambiguous error reporting on credential acquisition in multi-mechanism environments. The topic was tabled for future consideration as part of broader multi-mechanism support matters. Difficult issues include the acceptable relations among the identities which the different credentials may represent, further complicated by the fact that their name types may not necessarily be identical or even comparable. An ADD_CRED facility would need to accept only the same name as used by other elements in the credential set to which it was appending, given the fact that INQUIRE_CRED outputs only one name as an output. Much of the motivation for iterative credential set building derives from the desire to shape the default credentials which will be used when INIT_CONTEXT is called without an explicit CRED_HANDLE; Ted Ts'o suggested that we consider whether reconstruing the default credential construct as a default credential set might provide a feasible approach to this issue. 4. Graceful, Confirmed Context Shutdown; Context Deletion Semantics This issue relates to a suggestion that DELETE_SEC_CONTEXT support CONTINUE status and, by implication, that PROCESS_CONTEXT_TOKEN be able to return an output token in order to accomplish a graceful, confirmed context shutdown. It was argued that handshaking to accomplish an effective multi-phase commit before tearing down context resources should be considered wholly an application-level matter, above GSS-API. Beliefs were also expressed that the context deletion token which DELETE_SEC_CONTEXT may now emit is superfluous, and that a context deletion primitive should have a wholly local effect. Three tiers of possible function were identified: (1) release local resources, generating no token; (2) generate a token to notify the remote peer to release its resources (if used, (2) should be invoked before (1), so the context's resources can still be used to protect the generated token); (3) confirmed close with semantics as used in ACSE. Relative to FTP Security as an example, Steve Lunt noted that an explicit close as in (3) wouldn't be needed; its applicability could be somewhat more apparent for applications which use multiple security contexts serially within a communications association. Little sentiment appeared among attendees for case (3); the current proposal in this area is that we add, in V2, a new, additional RELEASE_SEC_CONTEXT call which would be wholly local in significance and recommended in preference to DELETE_SEC_CONTEXT. 5. Stream Protocol Support This topic concerns extensions for efficient support of data protection in stream-oriented protocols like TELNET, where the size of an individual data unit to be processed is often only a single byte and where optimization of cryptographic processing cycles can be a significant issue. (There was debate, however, about whether encrypted rlogin, which typically executes a full DES cycle per character, was unacceptably slow in operational use.) Use of OFB mode encryption, as has been used to protect TELNET traffic, was discussed but does not directly provide integrity. After discussion, it was recommended that mechanisms could (optionally) support such features through use of special QOP values. OID Assignments Formal OID assignments for Kerberos V5 mechanism name types will be made by MIT. Detailed Points RE: RFC 1509 In the final minutes of the meeting, Marc Horowitz raised for discussion some detailed points regarding RFC 1509 which had previously been posted in a message to the mailing list. Only a subset of the list was covered. Two specific points raised and accepted include: should legitimately be able to pass a zero-length token as input to an initial call to INIT_SEC_CONTEXT, and need to fix RFC 1509's erroneous typographic segue (p. 40) from a call's description into gssapi.h. It was observed as desirable that GSS-API implementations be shippable as shared libraries without source code. Such object-level compatibility would require at least uniformly-accepted structures for four typedef values; Marc will make a follow-up proposal to the mailing list for discussion. Attendees Garrett Alexander gda@tycho.ncsc.mil Perkins Bass bass@eskimo.com Kym Blair kdblair@dockmaster.ncsc.mil Uri Blumenthal uri@watson.ibm.com Michael Bringmann michael@rd.qms.com J. Nevil Brownlee nevil@ccu1.aukuni.ac.nz David Carrel carrel@cisco.com Wallace Colyer wally+@cmu.edu Stephen Crocker crocker@tis.com Shane Davis shane@delphi.com Terry Davis tld5032@commanche.ca.boeing.com Cheri Dowell cdowell@atlas.arc.nasa.gov Havard Eidnes havard.eidnes@runit.sintef.no Antonio Fernandez afa@bellcore.com Jerome Freedman jfjr@mbunix.mitre.org Dennis Glatting dpg@ocsg.com Chris Gorsuch chrisg@lobby.ti.com Richard Graveman rfg@ctt.bellcore.com Dragan Grebovich dragan@bnr.ca Marco Hernandez marco@cren.net Jeff Hodges hodges@jessica.stanford.edu Marc Horowitz marc@security.ov.com Jim Hughes hughes@network.com Vince Jones 72077.1615@compuserve.com Robert Karsten robert@lachman.com Charlie Kaufman kaufman@zk3.dec.com Hiroshi Kawazoe kawazoe@trl.ibm.co.jp Sean Kennedy liam@nic.near.net Edwin King eek@atc.boeing.com Peter Kirstein P.Kirstein@cs.ucl.ac.uk John Larson jlarson@parc.xerox.com Seung-Hwa Lee shlee@garam.kreonet.re.kr Ben Levy seven@ftp.com John Linn linn@security.ov.com Wen-Pai Lu wpl@bss.com Steven Lunt lunt@bellcore.com Yosi Mass yosi@ubique.co.il Piers McMahon p.v.mcmahon@rea0803.wins.icl.co.uk Marjo Mercado marjo@cup.hp.com Michael Michnikov mbmg@mitre.org Keith Moore moore@cs.utk.edu Bob Morgan morgan@networking.stanford.edu Stephen Nahm sxn@sun.com Clifford Neuman bcn@isi.edu Chris Newman chrisn+@cmu.edu Hilarie Orman ho@cs.arizona.edu Peter Phillips pphillip@cs.ubc.ca Derrell Piper piper@tgv.com Michael Ressler mpr@ctt.bellcore.com Chris Seabrook cds@ossi.com Sam Sjogren sjogren@tgv.com Don Stephenson don.stephenson@sun.com Tony Valle valle@huntsville.sparta.com Raymond Vega rvega@cicese.mx Dale Walters walters@osi3.ncsl.nist.gov Grace Wiechman gw@cray.com John Wray wray@tuxedo.enet.dec.com Suguru Yamaguchi yamaguti@wide.ad.jp Kisong Yoon kysoon@garam.kreonet.re.kr Dan Zerkle zerkle@cs.ucdavis.edu Glen Zorn glenz@ocsg.com