Draft CAT minutes for Houston
John Linn <linn@security.ov.com> Tue, 09 November 1993 15:48 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06322; 9 Nov 93 10:48 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06306; 9 Nov 93 10:48 EST
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa10818; 9 Nov 93 10:48 EST
Received: by bitsy.MIT.EDU id AA27460; Tue, 9 Nov 93 10:31:01 EST
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP id AA27454; Tue, 9 Nov 93 10:30:59 EST
Received: from pad-thai.aktis.com by MIT.EDU with SMTP id AA10693; Tue, 9 Nov 93 10:30:50 EST
Received: from winkl.aktis.com by pad-thai.aktis.com (8.6.4/) with SMTP id <KAA21437@pad-thai.aktis.com>; Tue, 9 Nov 1993 10:31:33 -0500
Received: by winkl.aktis.com (4.1/4.7) id AA15122; Tue, 9 Nov 93 10:31:32 EST
Message-Id: <9311091531.AA15122@winkl.aktis.com>
To: cat-ietf@mit.edu
Cc: linn@security.ov.com
Subject: Draft CAT minutes for Houston
Date: Tue, 09 Nov 1993 10:31:31 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: John Linn <linn@security.ov.com>
CAT fanciers: Please send any comments against these minutes to the list by Monday, 15 November, so that they can be reflected in the version to be sent to the IETF Secretariat later that week. Regards, ... --jl --------cut here--------- Common Authentication Technology (CAT) minutes for Houston IETF, compiled by John Linn (additional minutes re FTP Security pending from Sam Sjogren): OVERVIEW The CAT WG met for two sessions in Houston. We reviewed status of ongoing activities, 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 are scheduled to become 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/1509, targeting inclusion in eventual Draft Standard versions to supplant those RFCs and comprise a "Version 2" GSS-API. Related topics to be discussed further 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 NAS Requirements WG described their currently-contemplated architecture, as input to determining how the CAT WG and technology might support their needs. Ran Atkinson gave a presentation on the Internet Authentication Guidelines Internet-Draft, receiving and soliciting comment from the WG. STATUS REVIEW Ted Ts'o (MIT) 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 (OpenVision) stated would also be distributed in December. No effort on a Kerberos V4 GSS-API implementation is known; should anyone have available and motivated resources to undertake this project, it should be technically feasible. Ted Ts'o offered to review and contribute to a design spec for KV4 GSS-API, if anyone wishes to drive this activity. Piers McMahon (ICL) 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 We discussed the procedure through which we would reflect and characterize any changes and extensions to be made to 1508 and 1509. We declared the current RFCs as constituting "GSS-API Version 1", and will generate successor Internet-Drafts enroute to the eventual next level of RFC publication which would become "GSS-API Version 2" [aka in these minutes as 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 group 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, short of this, 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 at the meeting that 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. We spent some time discussing the level of portability to be supported by GSS-API mechanisms, and agreed to take feasible and apparent measures in the interests of supporting object-level portability across different implementations. Specifically, we agreed that 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, we 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 group 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. PIERS MCMAHON PRESENTATION ON MULTI-MECHANISM ISSUES Piers McMahon (ICL) gave a presentation entitled "GSS-API IN A MULTI-MECHANISM ENVIRONMENT", discussing 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 specialisation 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. The following slide presents the structure of SESAME's GSS-API implementation: 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 (NRL) gave a presentation on the Internet-Draft (draft-haller-auth-requirements-01.txt) he had co-authored with Neil Haller (Bellcore), in order to solicit comments from the interested 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 vs. machine-oriented, orientation to point-to-point vs. 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 (Merit) 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 mailing list is nas-req@merit.edu. 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 is to 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.
- Draft CAT minutes for Houston John Linn