Editor's Note: These minutes have not been edited. CAT-WG MINUTES FOR MEMPHIS MEETING Revised draft, 14 April 1997 Minutes compiled by John Linn (OpenVision) QUICK SUMMARY The Common Authentication Technology (CAT) WG met for a single session at the Memphis IETF. Several Internet-Drafts regarding extension proposals to Kerberos protocol (Public-Key Utilizing Tickets for Application Servers (PKTAPP), Public-Key Cryptography for Initial Authentication in Kerberos (PKINIT), Public-Key Cryptography for Cross-Realm Authentication in Kerberos (PKCROSS), Kerberos Change Password Protocol (CHG-PASSWORD), and Integrity Protection for the Kerberos Error Message (KERBEROS-ERR-MSG)) were presented and discussed. Discussions were initiated on work to enable Kerberos operation in firewall environments. Status of the FTP Security draft (ftpsec-09), currently in IETF Last-Call and therefore under IESG jurisdiction, was reviewed. Ongoing progress was reported in defining a facility for protecting the Simple GSS-API Negotiation Mechanism (SNEGO)'s negotiation facility; it is anticipated that this facility, along with responses to other SNEGO comments, will be incorporated within a revised SNEGO draft to be issued within the next few weeks and subsequently placed into WG Last-Call targeting advancement to Proposed Standard. An initial Internet-Draft revising RFC-1510 (Kerberos protocol) is anticipated this week; it is intended that a successor version to be published a few weeks later will comprise the basis for advancement to Draft Standard. A revised version of the Independent Data Unit Protection (IDUP) draft was presented and discussed; a subsequent version responding to comments, and an associated IDUP C bindings draft, is anticipated in the next few weeks. Limited discussion of the GSS-V2 C bindings draft was undertaken; it is intended that a draft memo describing the alignments and corrections required to RFC-2078 be distributed to the mailing list by the first half of May. GENERAL DISCUSSION The list of active CAT-relevant Internet-Drafts was reviewed. Denis Pinkas (Bull) stated that no comments had been received from the WG on the XGSS and SESAME mechanism drafts, and reiterated a solicitation for their discussion. The XGSS draft was recently reissued to renew its currency at the I-D repository, but its content has not changed. KERBEROS EXTENSIONS: PKTAPP Ari Medvinsky (CyberSafe) gave a presentation on the new PKTAPP draft: approximately 4 attendees indicated that they had reviewed this document. Indicated motivations for PKTAPP: create within a single Kerberos extension an authentication solution combining public-key and Kerberos technologies, integrate Sirbu and Chuang's (CMU) PKDA concepts, and leverage PKINIT. Ari stated that PKTAPP enables interoperability between public-key and Kerberos infrastructures, using public-key certificates as the basis for Kerberos TGT acquisition. He also stated that PKDA performs public-key client-server authentication without a KDC, while retaining advantages associated with use of Kerberos tickets (e.g., short-lived credentials). Ari identified the following issues re PKTAPP: - Use a local KDC (per machine) or instead modify application services? Ari recommended an approach which doesn't require modifying applications. Some discussion about delegation options and alternatives ensued. - Naming approach: X.500 vs. Kerberos? Ari recommended that X.500 names be used. - API: should PKTAPP be supported under GSS-API or not? Ari was neutral. Denis Pinkas asked how a PKTAPP/PKDA approach would compare to SPKM. Ari disclaimed detailed familiarity with SPKM, but referenced SSL/TLS by comparison. PKTAPP enables multiple secret-key contexts to be established with a single public-key operation, but otherwise it was believed (at a coarse level) that the approaches were similar. KERBEROS EXTENSIONS: PKINIT AND PKCROSS Brian Tung (ISI) led discussion on the PKINIT and PKCROSS I-Ds. Regarding PKINIT, approximately 10 attendees indicated that they had been reviewing the drafts. In the latest version, the KDC recovery feature has been removed for lack of indicated interest. A reference implementation is available: see http://gost.isi.edu/info/kerberos/distribution.html. Brian's issues list (available at http://gost.isi.edu/brian/security/pk_init.html, and posted to the CAT mailing list) identifies items which he believes need to be resolved prior to WG Last-Call. An attendee commented that it might be necessary to accomodate TCP support, not now present, in order to carry large-sized certificate chains; this was accepted as an issue. An additional issue, regarding addition of CAs to the transited field, had previously been raised on the CAT list and was reiterated for consideration. Denis Pinkas observed that the current draft's treatment of signature keys represented improvement relative to its predecessor, but requested additional changes; Bill Sommerfeld (HP) noted his perception that the residual dispute might be unreconcialiable to the satisfaction of all interested parties. Approximately 8 attendees indicated that they had been reviewing PKCROSS drafts. The current draft incorporates a new scheme for ticket-based key distribution, with relevant information cached in profiles for efficiency, and an added mechanism for determining trust. Information is available at http://gost.isi.edu/brian/security/pk_cross.html; as with PKINIT, the PKCROSS issues list has been posted to the CAT list to solicit discussion. KERBEROS EXTENSIONS: CHG-PASSWORD Marc Horowitz (Cygnus) spoke briefly on the CHG-PASSWORD draft which he had submitted; approximately 6 attendees indicated familiarity with this draft. He stated that implementation work is underway at Cygnus, and that the result could likely be donated into the MIT code base. Ted Ts'o (MIT) noted that another, earlier proposal with similar functionality has been implemented in Xyplex terminal servers and is supported in MIT's Kerberos V5 release 1.0, though is not currently documented in I-D form; it was believed that the particulars of Marc's proposal were simpler than those of the earlier proposal, but Ted offered to circulate that earlier proposal as an I-D following the meeting, in order that the alternatives can be compared within the WG to determine their relative merits. KERBEROS EXTENSIONS: KERBEROS-ERR-MSG Matt Hur (CyberSafe) led discussion on the KERBEROS-ERR-MSG I-D. Given that the error structure as defined in RFC-1510 has no checksum field, the proposed approach is to place a checksum in an e-data type field, thereby providing a code-independent means to return integrity-protected error data; the approach is intended to be compatible with existing Kerberos implementations. Reserved type field value ranges are required to avoid collision with preauthentication data type values. The format of the error-representing structure is ASN.1/DER encoded. Bill Sommerfeld observed that extra, trailing fields can be added compatibly to ASN.1 objects through use of explicit tagging, and asserted that this type of approach would be cleaner. The rationale for providing the err-msg scheme was described as enabling a client to determine whether or not to believe an error message (e.g., "password invalid"), but several attendees questioned the need for such a facility. KERBEROS AND FIREWALLS Bill Sommerfeld spoke briefly to solicit follow-up list discussion on Kerberos usage in firewall environments. Identified issues include: relaying requests, addresses in tickets, location of relays, multi-hop support, and Kerberos over TCP (described as "part of the solution, not all of it".) Cliff Neuman noted that the IANA has assigned both TCP and UDP ports for Kerberos. FTP SECURITY FTP Security (ftpsec-09) is in IETF Last-Call and therefore under IESG jurisdiction. Implementor organizations represented at the meeting included Trusted Information Systems, Cygnus, and Spyrus. Marc Horowitz reported that simple changes are being made to enable use of TLS as a facility to protect FTP. Per direction received from the Security AD, a revised I-D reflecting changes and comments is to be submitted. NEGOTIATION MECHANISM Negotiation mechanism issues and proposals have been the subject of active discussion on the CAT mailing list during recent weeks. Denis Pinkas summarized the current situation. The current snego-03 draft includes optimistic negotiation, based on a contribution submitted by Peter Brundrett (Microsoft), which avoids the need for an extra round trip to accomplish negotiated context establishment when the initiator's preferred mechanism is accepted by a context's target. The current proposal works well in selecting among comparably-strong mechanisms, but is vulnerable to rollback attacks forcing selection of a weaker alternative if mechanisms of varying strengths are supported and proposed. Bill Sommerfeld presented the results of a recent side discussion involving WG members interested in negotiation and its protection, which yielded an approach for protecting negotiation within the SNEGO framework. In this approach, all tokens in a context establishment sequence are encapsulated; the final token includes (assuming that a MIC-capable mechanism is selected) a MIC computed on selection elements. Bill Sommerfeld is to provide, within the IETF week, text to Denis defining the draft protection enhancement; the result is planned for inclusion in another SNEGO draft in the next few weeks, to be placed subsequently into WG Last-Call targeting advancement to Proposed Standard. Marc Horowitz, who had offered an alternate protected negotiation proposal to the WG, indicated his willingness to accept a protection-enhanced version of SNEGO as the WG's approach. FOLLOW-UP PLANS FOR CURRENT RFCs Cliff Neuman (ISI) spoke on the current status of the successor document to RFC-1510 (RFC-1510bis). He intends to produce a first successor draft within the IETF week, and solicited any added comments needing to be included. A successor draft is intended within several weeks, and to be targeted for advancement to Draft Standard; incompatible protocol changes are not planned, and it is intended that RFC-1510bis will not inconvenience the existing installed Kerberos base. A preliminary summary of issues to be handled was sent to the mailing list and presented at the meeting. Cliff intends to clarify that possession of a ticket doesn't confer authorization, given the recognition that different KDCs might apply different (or no) authorization policies. He noted the fact that several Kerberos extension I-D's exist, and that additional extension work has been undertaken outside the IETF; he intends to add material about how such extensions could be used, but not to incorporate them within the standards track specification. MIT-accumulated errata and newly-defined triple-DES e-types will be included. Issues identified for list discussion, and possibly to be included in the successor I-D, include transited field processing and error message integrity. Regarding RFC-1964, it was observed that definition of new encryption types would likely be appropriate in order to support triple-DES. It was considered that this should be addressed most appropriately once RFC-1510bis is stable. IDUP Carlisle Adams (Entrust) led discussion on the current idup-07 draft. Approximately 5 attendees indicated that they had reviewed the draft. Comments had been received on the mailing list from John Wray (Digital), but have not yet been addressed in this version. Changes in idup-07 include a new idup_acquire_cred_with_auth() call with an additional "authenticator" parameter carrying a password or PIN; Carlisle described this call as non-mandatory, and stated that it was added upon request of an IDUP consumer. New cred_usage values were added. New evidence-related calls were added, per requests from Denis Pinkas. Various wording changes were made in response to comments from several reviewers, and changes were made to protection options. IDUP's SE and EV calls are intended to be easier for calling applications to employ when straightforward tasks are to be performed; more general calls within the specification are considered necessary in order to satisfy more complex application requirements. Within the next couple of months, Carlisle intends to submit another IDUP draft (responsive to John Wray's comments) and a corresponding IDUP C bindings specification. In closing discussion, Bengt Ackzell suggested addition of a new call (GSS_List_internal_names()) which would enumerate multiple names associated with a given context. When considered, this appeared more applicable to IDUP than to base GSS; it may be discussed further on the mailing list as a candidate IDUP facility. GSS-V2 / C BINDINGS Limited discussion of the GSS-V2 C bindings draft was undertaken; approximately 4 attendees indicated that they had reviewed this most recent version. John Linn suggested that all individuals concerned with the areas changed in the cbind-04 draft should validate that those changes are suitable and satisfactory; he intends to distribute a draft memo describing the alignments and corrections required to RFC-2078, and related issues, to the mailing list by the first half of May.