CURRENT_MEETING_REPORT_ Reported by John Linn/OpenVision Minutes of the Common Authentication Technology Working Group (CAT) The CAT Working Group met for two sessions in Toronto, with a total of 58 rostered attendees. Approximately half of the attendees had attended one or more previous CAT meetings, and approximately one third were subscribed to the working group mailing list. Carlisle Adams gave a presentation on the Simple Public-Key Mechanism (SPKM), a proposed GSS-API mechanism based on public-key technology, offering 2-way and 3-way authentication exchange variants, generalized use of OIDs for flexibility, parameter negotiation, and provisions for non-repudiation services. Rough consensus was reached on outstanding issues of GSS-API buffer sizes, continuation processing of long messages, and context expiration, pending review by the mailing list. Advancement of FTP security is pending revision of the Internet-Draft. We also received a presentation on IMAP authentication by John Myers. Topics receiving significant discussion, summarized in later sections of these minutes, included: o The Simple Public-Key Mechanism (SPKM) o Interactive Mail Access Protocol (IMAP) authentication o Context expiration in Kerberos V5 mechanism and GSS-API o Continuation processing and large message handling in GSS-API Short Topics In opening agenda discussion, P. Rajaram asked whether discussion of authorization extensions to GSS-API, such as those proposed in X/Open by Project SESAME, was an appropriate topic for CAT Working Group discussion. Piers McMahon commented that the SESAME work was outside the CAT Working Group's current scope. It was also noted that a separate IETF Authorization and Access Control Working Group (AAC) exists and is chartered to pursue such activities, but has not met recently. Other topics, discussed briefly, included: Kerberos principal object support: Working group members were asked to review the text in ``The Kerberos Version 5 GSS-API Mechanism'' (draft-ietf-cat-kerb5gss-01.txt) proposing routines for import and export of non-printable name objects and to consider whether these routines should be migrated to successors to RFCs 1508 and 1509. Negotiated mechanism: Don Stephenson and P. Rajaram to investigate reactivation of former work, possible availability of code; any added application requirements for negotiation solicited (one desirable: be able to make the negotiation messages compact for insertion within existing size-limited protocols; another, enable ordered preferences to be specified). ``SERVICE'' prefix for service names: Ted Ts'o to send note to list summarizing issues and background. This prefix had been used to distinguish service entities, in conjunction with a null mechanism type. Its use now appears redundant along with the service name type, as described in the current draft, which serves as a hint to gss_import_name() as to how to process a name in the course of importation. There are some backward compatibility issues with existing code. We need to decide how, and whether, to preserve use of this convention. Store-and-forward support service extensions to GSS-API: no consensus within group on pursuing this topic at the meeting, but discussion is proceeding on the mailing list. P. Kirstein and P. McMahon noted that the European Community's TDP consortium is interested in using (or defining, if needed) GSS-API-compatible extensions in this area, and that there would be interest in any work which might emerge from the IETF. Service-to-client one-way authentication (as desired, e.g., for use by some Mosaic services): at present, best available approach is to authenticate mutually from accessing client to server, even though the client-server path is not an application requirement. It is also possible, if supported by an underlying mechanism, to apply one-way authentication on a context initiated by the Mosaic service and accepted by the Mosaic client. Buffer sizes across GSS-API interface: It was believed that the 2Kbyte threshold included in draft-ietf-kerb5gss-01.txt was smaller than desirable, and that a change to 16Kbytes would be acceptable to known implementors and would permit more efficient operation. It is therefore proposed that the limit be increased to 16Kbytes. Stream support (``CATS'' protocol): Ted Ts'o to resend working notes to list. Status of FTP security draft: Pending revision in response to posted comments. SPKM Presentation Carlisle Adams gave a presentation on a proposed Simple Public-Key Mechanism (SPKM), as described in Internet-Draft ``The Simple Public-Key GSS-API Mechanism (SPKM)'' (draft-ietf-cat-spkmgss-00.txt). SPKM is based on a public key infrastructure, offers (as separate mechanisms with different OIDs) 2-way and 3-way mutual authentication (thereby available to environments without secure time); uses OIDs wherever possible to allow maximum flexibility and growth; uses negotiation at context establishment time to allow interoperability between environments (for SPKM-specific parameter negotiation, within the mechanism); QOP parameter (from application) selects the data integrity mechanism to be used; non-repudiation can be applied to context if desired. BNR's work began with an interface for store-and-forward messaging support, subsequently generalized for on-line, association-oriented operation. BNR intends to offer the proposal as the basis for an Internet standards-track protocol. The development and distribution status of a reference implementation for SPKM is not currently known, but implementation is underway at Northern Telecom and/or BNR, and feedback on the proposed approach is solicited. Example tokens and exchanges were presented: A Req_Token initiates all exchanges. The token structure is X.509-compliant, with some elements optional. A key establishment OID's value describes the exchange which is to follow. Context_Data provides the parameters describing a context. The Seal token bears OIDs for each of the integrity, sequence, and confidentiality algorithms: it carries an explicit OID if the parameters established at context initiation allow more than one, and is otherwise NULL. Alignment and padding of variable-length fields was discussed. Issue: How do you handle later validation of a long-term signature, once the context handle is no longer valid? Long-term signing was an interest and a design consideration but is not a requirement. Carlisle's conclusions slide summarized the following observations: SPKM has advantages over alternatives, in terms of flexibility, non-repudiation, negotiation support and no required reliance on secure timestamps. IMAP Authentication In the CAT Working Group's second session, John Myers led a discussion on Interactive Mail Access Protocol (IMAP) authentication. This approach, currently in Last Call for advancement to Proposed Standard, implements an IMAP4 AUTHENTICATE command, based on FTP security's AUTH/ADAT commands. It identifies authentication mechanisms by name, and supports an arbitrary number of base64-encoded exchanges. Privacy and integrity protection are supported; the authorization userid is independent of the authentication ID. In contrast to FTP security, there is no separate data versus control channel. User ID, protection mechanism and buffer size are negotiated during the authentication exchange. Use of a protection mechanism is optional. IMAP authentication has no interaction with plain-text login. Examples were shown using Kerberos V4 and S/Key; a GSS-API mechanism is defined as well (protecting option exchange with GSS_Seal()). GSS-API and S/Key mechanisms are not yet implemented; Ted Ts'o expressed interest in integrating with the Kerberos V5 development stream via GSS-API if the IMAP code is distributable. In the IMAP Kerberos mechanism, the client closes out the exchange by mutually authenticating back to the server and declaring accepted service options. Design intentionally uses server-issued challenges, so as to protect against replays even within the Kerberos 5 minute timestamp window. Could not use S/Key with FTP security as it stands, since the FTP security draft demands integrity on negotiation. It was suggested that we consider changing the FTP security draft to enable conformant use of S/Key. Discussion of Proposed GSS-API Continuation Processing of Long Messages During the course of the SPKM presentation slot, Carlisle Adams suggested a GSS-API extension to accept segments of long buffers with continuation flag parameters: add to gss_seal an ``end_flag'' which can accept GSS_S_CONTINUE_NEEDED and add to gss_unseal the ability to indicate that non-final versus final segments are being emitted. Ted Ts'o noted that the primary problem in the area of long message processing is that the sender does not know how big a token the receiver can handle. Carlisle was more concerned with the local interface issue than with the issue of sizes supported by remote peers. Bill Sommerfeld observed that applications and GSS-API should ``cooperate'' in terms of segment sizes. The argument was made that the use of sequencing mechanisms and per-message integrity versus a single binding signature spanning multiple data units is sufficient within the scope of an association-oriented context; the binding signature might be more valuable in a store-and-forward document scenario. Three possible measures present themselves: 1. Application calls a new GSS-API facility to find out how big a token it can pass in in order to get an output token no bigger than the maximum acceptable size. Compression can introduce variability in the output size which will result for different data of the same input size. The new facility needs to accept as input the QOP value which is to be requested for data protection. Action: Incorporate this facility for GSSV2. 2. Constrain mechanisms so that arbitrary fragments, split within the GSS-API or below, can be independently validated. The group agreed not to impose this constraint. 3. There was interest in a facility to distinguish an ordered stream of non-initial segments from a final segment. P. Rajaram argued that this would resolve the issue of not having enough memory to process the data unit as a whole. Controversy revolved around whether this was an appropriate facility at the level of the interface rather than an application-specific issue above the interface. In Ted Ts'o's proposed CATS package, connection close was indicated explicitly by the CATS protocol, rendering moot the need to distinguish a final message at the level of the GSS-API interface. After discussion, we resolved (pending mailing list confirmation) not to incorporate interface-level message continuation facilities. Context Expiration We discussed context expiration within the Kerberos mechanism, distinguishing enforced expiration (disabling per-message protection when expiration time is reached) versus advisory expiration (continuing to perform per-message protection operations, with informatory status) versus no expiration. Advisory and enforced expiration cases can be further subdivided into uniformly-performed expiration versus expiration performed only if requested by a caller at context expiration time. Much of the interest in application-selectable expiration relates to use as a trigger to garbage collect keys and related data. Possible inputs to an expiration policy would include (some combination of) user-requested time, expiration time(s) of relevant tickets, local configuration data and input received from a peer. In any of these scenarios, except ``no expiration,'' applications must be able to accommodate the occurrence of a no-longer-valid context, effectively renewing by initiating a new one. It was suggested as a possibly useful extension for init_context or an alternative routine thereto to be able to accept an existing context handle as input for renewal through establishment of a new context, but no detailed exploration or conclusion on this suggestion was reached. A prospect of ``soft expiration,'' where advisory errors would be received at a point in time before the context no longer operated, was discussed but rejected as introducing unneeded complexity and being ineffective for recovery after a context has been idle across both of its ``soft'' and ``hard'' expiration times (e.g., after a user walks away from a terminal, returns sometime later, and attempts to resume a session). It was also observed that an application desiring a ``soft'' warning could easily pass a time value appropriately less than the context_time output as received from init_sec_context to an OS-specific timer facility outside GSS-API. In initial discussion relative to the Kerberos mechanism, popular sentiment favored no expiration, but a range of views were expressed. Bill Sommerfeld noted that DCE enforces hard expiration (with some time windowing), but that this appeared more feasible in the DCE RPC environment where RPC calls are typically short-lived than in the general GSS-API case. In DCE RPC, expiration is enforced only for call establishment, not within an already-established call. Ted Ts'o asserted that expiration should not be enforced for at least the class of rlogin-like applications, to avoid disrupting outstanding associations. P. Rajaram also argued that enforced expiration was unacceptably disruptive for certain applications, and that advisory expiration was not a useful service for GSS-API to provide; Bill Sommerfeld observed that advisory expiration could be a convenient timing service, but that the motivation did not appear compelling. Piers McMahon observed that context expiration did not enable a useful policy enforcement mechanism, recognizing that use of all GSS-API facilities is at an application's discretion. Jeff Schiller proposed that no context should last forever, and that for the Kerberos mechanism the expiration time should be no later than the expiration of the ticket(s) which are used to establish the context; other inputs (e.g., caller request, configuration) could result in an earlier expiration time. P. Rajaram argued that context expiration should not be forced by ticket expiration times, but should instead be based on an administratively-configurable parameter. After active discussion, Jeff's approach was accepted as our working proposal. Rationales discussed included: (a) programs like rlogin were not likely to be using GSS-API, for reasons of performance in character-at-a-time applications, and (b) applications for which expiration was unacceptable could perform their own encryption outside GSS-API, possibly using a GSS-API context as a means to securely transfer their own keys. Mailing list discussion on context expiration topics is continuing.