NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
John Linn <john.linn@ov.com>
Jeffrey Schiller <jis@mit.edu>
General Discussion:cat-ietf@mit.edu
To Subscribe: cat-ietf-request@mit.edu
Archive: ftp://bitsy.mit.edu/cat-ietf/archive/
The goal of the Common Authentication Technology (CAT) Working Group is to provide distributed security services (including authentication, integrity, and confidentiality) to a variety of protocol callers in a manner which insulates those callers from the specifics of underlying security mechanisms.
By separating security implementation tasks from the tasks of integrating security data elements into caller protocols, those tasks can be partitioned and performed separately by implementors with different areas of expertise. This provides leverage for the IETF community's security-oriented resources, and allows protocol implementors to focus on the functions their protocols are designed to provide rather than on characteristics of security mechanisms. CAT seeks to encourage uniformity and modularity in security approaches, supporting the use of common techniques and accommodating evolution of underlying technologies.
In support of these goals, the working group pursues several interrelated tasks. We have defined a common service interface allowing callers to invoke security services in association-oriented environments, with an associated token format identifying the security mechanism being employed. A revision to this document set is currently being finalized in response to implementation experience. The CAT Working Group also defines underlying mechanisms to provide security services, and supports integration of security services into caller protocols. Related work areas include interface and mechanism extensions under consideration for message protection in store-and-forward environments and for authorization support.
Goals and Milestones:
· Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API)
· Public Key Cryptography for Initial Authentication in Kerberos
· Generic Security Service API Version 2 : C-bindings
· Independent Data Unit Protection Generic Security Service Application Program Interface: C-bindings
· Simple GSS-API Negotiation Mechanism
· The SESAME V5 GSS-API Mechanism
· Extended Generic Security Service APIs: XGSS-APIs Access control and delegation extensions
· Public Key Cryptography for Cross-Realm Authentication in Kerberos
· Key Derivation for Kerberos V5
· Triple DES with HMAC-SHA1 Kerberos Encryption Type
· Public Key Utilizing Tickets for Application Servers (PKTAPP)
· Kerberos Change Password Protocol
· Integrity Protection for the Kerberos Error Message
Request For Comments:
Minutes for the CAT-Working Group
Reported by: John Linn (OpenVision)
The Common Authentication Technology (CAT) Working Group 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. On-going 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 Working Group 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.
The list of active CAT-relevant Internet-Drafts was reviewed. Denis Pinkas (Bull) stated that no comments had been received from the Working Group 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.
III. KERBEROS Extensions: PKTAPP
Ari Medvinsky (CyberSafe) gave a presentation on the new PKTAPP draft: approximately four 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 that 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.
IV. KERBEROS Extensions: PKINIT AND PKCROSS
Brian Tung (ISI) led discussion on the PKINIT and PKCROSS I-Ds.
Regarding PKINIT, approximately ten attendees indicated that they were reviewing the drafts. In the latest version, the KDC recovery feature has been removed or 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 Working Group Last-Call. An attendee commented that it might be necessary to accommodate 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 represents improvement relative to its predecessor, but requested additional changes; Bill Sommerfeld (HP) noted his perception that the residual dispute might be unreconciliable to the satisfaction of all interested parties.
Approximately eight attendees indicated that they were 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.
V. KERBEROS Extensions : CHG-PASSWORD
Marc Horowitz (Cygnus) spoke briefly on the CHG-PASSWORD draft which he submitted; approximately six 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 an earlier proposal with similar functionality has been implemented in Xyplex terminal servers and is supported in MIT's Kerberos V5 release 1.0. Although is not currently documented in I-D form, it is believed that the particulars of Marc's proposal are simpler than those of the earlier proposal. Ted offered to circulate the earlier proposal as an I-D following the meeting in order that the alternatives can be compared within the Working Group to determine their relative merits.
VI. 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 pre-authentication 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.
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 (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 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 Working Group 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 Working Group Last-Call targeting advancement to Proposed Standard. Marc Horowitz, who had offered an alternate protected negotiation proposal to the Working Group, indicated his willingness to accept a protection-enhanced version of SNEGO as the Working Group's approach.
X. 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 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.
Carlisle Adams (Entrust) led discussion on the current idup-07 draft. Approximately five 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.
Limited discussion of the GSS-V2 C bindings draft was undertaken; approximately four 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.