CURRENT_MEETING_REPORT_ Reported by John Linn/OpenVision and Sam Sjogren/TGV Minutes of the Common Authentication Technology Working Group (CAT) Overview The CAT Working Group met for two sessions in Houston. The status of ongoing activities was reviewed, including a reworked GSS-API implementation for Kerberos V5 beta 3. This distribution, and an Internet-Draft describing its GSS-API mechanism characteristics and token formats, should be available later this year. Some interface clarifications and extensions (e.g., a new GSS_Inquire_context primitive) were discussed as inputs to Internet-Draft successors to RFCs 1508 and 1509, targeting inclusion in eventual Draft Standard versions to supplant those RFCs and comprise a ``Version 2'' GSS-API. Related topics to be discussed on the mailing list include multi-mechanism credential management and error reporting. Piers McMahon gave a presentation on SESAME's multi-mechanism implementation, and distributed a paper for comment. Sam Sjogren and Steve Lunt led a discussion on the FTP Security Internet-Draft, to be updated shortly and to be used as the basis for an interoperability test (using Kerberos V4 technology) planned for March 1994. Representatives from the Network Access Server Requirements Working Group (NASREQ) described their currently contemplated architecture as input to determining how the CAT Working Group and technology might support their needs. Ran Atkinson gave a presentation on the Internet Authentication Guidelines Internet-Draft, receiving and soliciting comment from the attendees. Status Review Ted Ts'o reported that two independent implementors are reworking the GSS-API implementation for Kerberos V5; it is expected that the result of one of these activities will be incorporated into Kerberos V5 beta 3, to be available as a redistributable release in December. (This step will replace and obsolete the ``alpha quality'' GSS-API in Kerberos V5 beta 2.) Detailed documentation, including token formats for the mechanism, is being prepared and will be included in an Internet-Draft which John Linn stated would also be distributed in December. No effort on a Kerberos V4 GSS-API implementation is known. Ted Ts'o offered to review and contribute to a design specification for KV4 GSS-API if anyone wishes to drive this activity. Piers McMahon provided hardcopy of a memo he drafted describing a framework for GSS-API extensions targeted for POSIX environments, and solicited comments. John Linn reported that the ongoing liaison with the X/Open Security Working Group is progressing well, and that the technical content of RFCs 1508 and 1509 is incorporated in a document currently undergoing X/Open Company Review for publication as an X/Open Preliminary Specification. Interface Extensions and Refinements The procedure through which any changes and extensions to be made to 1508 and 1509 would be reflected and characterized was discussed. The current RFCs were declared as constituting ``GSS-API Version 1,'' and successor Internet-Drafts will be generated enroute to become ``GSS-API Version 2'' (aka GSSV2). The GSS_Inquire_context() primitive, as discussed on the mailing list, was accepted as an addition for GSSV2. Renaming of the per-message primitives, per X/Open terminology request and as also discussed previously on the mailing list, was accepted as a change for GSSV2. The attendees discussed the issue of credential acquisition in a multi-mechanism environment, including a proposal made to the mailing list for definition of a new GSS_Add_cred() primitive to be used in preference to the current GSS_Acquire_cred(). Since GSS_Acquire_cred(), like other GSS-API calls, returns only a single pair of major_status and minor_status values, its use in a multi-mechanism environment cannot return specific information about each of the supported mechanisms for which credentials may or may not have been successfully acquired. Several attendees observed the fact that the need to disambiguate minor_status values is primarily of interest to callers embodying knowledge of mechanism-specific characteristics and needing to make decisions based on those characteristics, a class of callers which attendees sought to minimize. Despite this fact, some mechanism-cognizant callers (or callers seeking to display meaningful minor_status indications to their clients) will certainly exist, and it's appropriate to consider how they could be better served for GSSV2. In addition to the prior GSS_Add_cred() proposal, it was observed that callers requiring unambiguous per-mechanism status information could use the current GSS_Acquire_cred(), explicitly specifying a single mechanism per invocation, at the cost of losing the convenience of multi-mechanism credentials. [Though not cited in meeting discussion, the GSS_Indicate_mechs() primitive provides the necessary data for a caller to perform this iteration.] Following some discussion, John Linn accepted the action of further summarizing options and tradeoffs in a message to the mailing list. The level of portability to be supported by GSS-API mechanisms was discussed, and it was agreed to take feasible and apparent measures in the interests of supporting object-level portability across different implementations. Specifically, the forthcoming Kerberos V5 mechanism Internet-Draft should define a set of common minor_status values to be used by implementors of the mechanism, though additional minor_status codes specific to particular implementations are also possible. Further, it was agreed that the ``gssapi.h'' header file at the end of RFC 1509 should be considered part of the standard, noting that refinements and additional elements (e.g., type definitions for name representations having broader scope than a single mechanism) might be incorporated for GSSV2 and that particular implementations would likely append their own, implementation-specific definitions over and above gssapi.h. The attendees discussed a prior request to incorporate a form of per-message protection which would provide confidentiality without integrity, but did not elect to incorporate such a facility. Presentation on Multi-Mechanism Issues Piers McMahon (ICL) gave a presentation entitled ``GSS-API IN A MULTI-MECHANISM ENVIRONMENT,'' covering four topics: (1) problem domain, (2) architecture of GSS-API implementation by SESAME, (3) API implications, and (4) approaches to credential acquisition. Regarding the problem domain, Piers observed the following: (1a) today's (and probably tomorrow's) problem is heterogeneity, (1b) users expect single sign-on, and (1c) administrators expect single point of user registration. Regarding API implications, he cited internal structure constructs designed to separate the GSS-API layer from individual underlying mechanisms: internal APIs to deposit/append/clear credential elements, credential element/security context specialization features (function vectors, data), and use of a common cryptographic support facility (CSF) for all mechanisms. In terms of external elements (those visible to GSS-API callers), he noted that it was necessary to provide a single common view of timeouts and other attributes, spanning all underlying mechanisms. Regarding credential acquisition and related login functions, he cited three concepts: multiple login, use of shared data elements relevant to more than a single mechanism, and an ``access manager'' which would use, e.g., passwords or credentials for one mechanism as a basis for which to acquire credentials of another mechanism on behalf of a user. Architecture of GSS-API Implementation by Sesame Principal --owns-> Credential | contains one or more V Credential Element ^ inherits from | +---------- SESAME Credential Element initiate/ accept | Security Context --------uses---> Cryptographic | Support | ^ Facility | inherits from | | | +---------> SESAME Security Context Internet Authentication Guidelines Draft Ran Atkinson gave a presentation on the Internet-Draft he had co-authored with Neil Haller (draft-haller-auth-requirements-01.txt), to solicit comments from the IETF community. The document distinguishes four classes of authentication: none, disclosing (subject to passive attacks), non-disclosing (subject to active, but not to passive attacks), and strong (resistant to passive and active attacks); its pragmatic motivation is to encourage migration to at least the non-disclosing level. While this taxonomy was accepted as useful and primary, it was noted that technologies could also be distinguished on other grounds: human-oriented versus machine-oriented, orientation to point-to-point versus distributed system usage, and requirements for shared secrets. It was recommended that the document retain a consistent and specific focus on authentication, and that tutorial material be separated from commentary and opinion. It was noted that some of the content overlapped with sections of the Internet Security Architecture document being prepared by the PSRG; Jeff Schiller commented that he believed the documents were generally aligned, but that some work would be needed in order to assure that terminology definitions were consistent. As a particular example, Ran noted that he had observed U. S. Defense Department usage of the term ``digital signature'' as referring to integrity protection without non-repudiation, a form of usage inconsistent with much of the literature. Network Access Security Requirements (NASREQ) John Vollbrecht attended a portion of the CAT meeting in order to inform attendees on NASREQ's environment and concerns, to solicit comment, and to explore possible areas of overlap between the groups. Review of anticipated design documents was solicited. The NASREQ environment includes Network Access Clients (NACs, typically PCs) accessing Network Access Servers (NASs) via dial-up. It is planned that the NASs will communicate with authentication servers across a network, perhaps indirectly by way of ``helper'' devices. PPP is used across the dial-up link, presently with PAP and CHAP but with new KAP (Kerberos), PKAP (public key) and SCAP (smart card) authentication schemes contemplated but not yet documented; a brief explanatory memo will be distributed shortly. The ``RADIUS'' protocol is being considered as a basis for interaction between NASs and authentication servers. Mobility support, enabling users to connect to NASs in foreign domains (with multiple intermediary helpers between the access point and a user's home NAS) is desired and introduces inter-domain trust considerations. Two authentication types are currently distinguished within user records: ``UNIX'' (password-level) and ``Kerberos'' (in which a Kerberos server is involved in the process of authenticating a user for access to network resources via a NAS). It was suggested that Derek Atkins' MIT thesis on use of Kerberos in a dial-up environment represents an alternate approach worthy of consideration. GSS-API might be useful as a means to protect traffic between NASs and helpers and/or authentication servers, but its current underlying mechanisms are not oriented to operation across a dial-up link where clients lack independent access to authentication servers. FTP Security Since the Amsterdam IETF meeting the FTP security Internet-Draft (the current version is draft-ietf-cat-ftpsec-03.txt) had been changed by the author, Steve Lunt, to reflect discussions at that meeting. The changes were: o Principal name fallback (use ``rcmd'' if ``ftp'' doesn't exist) This would allow maximal flexibility for an administrator to restrict an FTP server and the environment it runs in, while allowing for simplification of administration by not requiring the configuration of new principals if a site wished to just use the ``rcmd'' principal which they would already have for use by Kerberized R-Services and Telnet and the like. Any restrictions on what principal must be used and other configuration issues would be implementation and site specific. o Changed GSS_Safe to GSS_Seal with conf_flag == False o Changed GSS_Verify to GSS_Unseal o Changed GSS_Seal to GSS_Seal with conf_flag == True o Changed the mailing list from ftp-wg@tgv.com to cat-ietf@mit.edu. There is a mail reflector at TGV which will remain in existence indefinitely. So, mail sent to ftp-wg@tgv.com will merely get forwarded to cat-ietf@mit.edu. It is recommended, however, that the cat-ietf address be used. There were two outstanding protocol length issues which were introduced for discussion leading to closure. First, the issue of the length of buffers allowed for protected file transfers, and second, the lack of restriction on the length of base-64 encodings. It is desirable to have a finite buffer size used for protected file transfers, as there may be situations in which a system would need to read an entire buffer into memory before being able to operate on it, and some systems have far more finite memory resources than others. However, specifying some arbitrarily small buffer size could have an impact on performance and even functionality. It was decided that a negotiation would be added to the protocol which would allow the client and server to agree on a buffer size. Steve will add the specification of this to the document. A base-64 encoding may be of arbitrary length. The binary authentication data that is encoded may be of arbitrary length. Although a line-wrapping scheme could be specified that would wrap lines and thereby limit the clear-text line length while allowing the arbitrarily long binary data, it was not felt that there was any need to do that. The document will be modified to note that the base-64 encoded data lines can be arbitrarily long without line-wrapping being used. The issue of a fall-back targ_name for the GSS-API specification for FTP was not resolved. The name ``SERVICE:ftp@hostname'' is currently specified, but it is unclear what would be a more common name to fall back to (as with the ``ftp'' to ``rcmd'' fallback in the Kerberos V4 specification). This issue will be resolved via e-mail. A request for adding state diagrams was made. This will be satisfied in a future revision of the document. Interoperability Bakeoffs Sam Sjogren led a discussion which proposed the idea of having ``virtual Bakeoffs'' between IETF meetings to motivate implementation of standards being worked on and interoperability testing of those implementations. A tentative date of the week of 14 March 1993 will be the target for a virtual bakeoff of the FTP Security work. Attendees Garrett Alexander gda@tycho.ncsc.mil Nick Alfano alfano@mpr.ca Alireza Bahreman bahreman@bellcore.com Luc Boulianne lucb@cs.mcgill.ca Chuck de Sostoa chuckd@cup.hp.com Antonio Fernandez afa@thumper.bellcore.com Steve Garritano steveg@kalpana.com Jisoo Geiter geiter@mitre.org Chris Gorsuch chrisg@lobby.ti.com Marco Hernandez marco@cren.net Charlie Kaufman kaufman@zk3.dec.com Walter Lazear lazear@gateway.mitre.org Gordon Lee gordon@ftp.com John Linn linn@security.ov.com Kanchei Loa loa@sps.mot.com Steven Lunt lunt@bellcore.com Chip Matthes chip@delphi.com Wayne McDilda wayne@dir.texas.gov Piers McMahon p.v.mcmahon@rea0803.wins.icl.co.uk Michael Michnikov mbmg@mitre.org Bob Morgan morgan@networking.stanford.edu Clifford Neuman bcn@isi.edu Rakesh Patel rapatel@pilot.njin.net Allan Rubens acr@merit.edu Jeffrey Schiller jis@mit.edu Wolfgang Schneider schneiw@darmstadt.gmd.de Vincent Shekher vin@sps.mot.com Sam Sjogren sjogren@tgv.com Frank Solensky solensky@ftp.com Dave Solo solo@bbn.com Don Stephenson don.stephenson@sun.com Jerry Toporek jt@mentat.com Theodore Ts'o tytso@mit.edu John Veizades veizades@ftp.com John Vollbrecht jrv@merit.edu