2.6.1 Common Authentication Technology (cat)

NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 10-Mar-00


John Linn <jlinn@rsasecurity.com>

Security Area Director(s):

Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortelnetworks.com>

Security Area Advisor:

Jeffrey Schiller <jis@mit.edu>

Mailing Lists:

General Discussion:ietf-cat-wg@lists.stanford.edu
To Subscribe: ietf-cat-wg-request@lists.stanford.edu
Archive: ftp://ftp.ietf.org/ietf-mail-archive/cat/

Description of Working Group:

The goal of the Common Authentication Technology (CAT) Working Group is to provide distributed security services (which have included authentication, integrity, and confidentiality, and may broaden to include authorization) 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 xpertise. 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 (GSS-API) allowing callers to invoke security services in association-oriented environments, with an associated token format identifying the security mechanism being employed. Existing documents provide C language bindings for GSS-API; currently ongoing work is defining bindings for Java. Authorization interfaces are currently being evaluated as a related area for follow-on work, with the level of achievable portability an important consideration. The CAT Working Group also defines supporting mechanisms to provide security services; current activity includes specification of "low-infrastructure" mechanisms to support ease of deployment and use.

Goals and Milestones:



Preliminary BOF session at IETF meeting, discussions with TELNET and Network Printing Working Groups.



Distribute Generic Security Service Application Program Interface (GSS-API) documentation through Internet-Draft process.



First IETF meeting as full working group: review charter distribute documents, and status of related implementation, integration, and consulting liaison activities. Schedule follow-on tasks, including documentation plan for specific CAT-supporting security mechanisms.



Update mechanism-independent Internet-Drafts in response to issues raised, distribute additional mechanism-specific documentation including Distributed Authentication Services architectural description and terms/conditions for use of the technology documented therein.



Second IETF meeting: Review distributed documents and status of related activities, continue consulting liaisons. Discuss features and characteristics of underlying mechanisms. Define scope and schedule for follow-on work.



Submit service interface specification to to the IESG for consideration as a Proposed Standard.



Submit GSS-V2 to IESG for consideration as a Proposed Standard.



Plan next phase of activities, with particular attention to scope and tasking for authorization, store and forward protection support, and additional mechanisms.



Submit Negotiated Mechanism document to IESG for consideration as a Proposed Standard



Issue Internet-Draft representing updated version of RFC-2078, aligned with GSS-V2 C bindings Internet-Draft.



Submit GSS-V2 C bindings document to IESG for consideration as a Proposed Standard.



Progress Internet-Draft and RFC publication of mechanism-level documents to support independent, interoperable implementations of CAT-supporting mechanisms.

Jul 99


Determine direction and intent re progressing authorization interfaces.

Jul 99


Determine direction and intent re progressing low-infrastructure mechanism definitions.

Aug 99


Submit GSS-V2 Java bindings specification to IESG for consideration as Proposed Standard.

Aug 99


Submit Kerberos Public-Key Initial Authentication (PKINIT) document to IESG for consideration as Proposed Standard.

Aug 99


Submit revision to Kerberos protocol specification to IESG as new Proposed Standard to succeed RFC1510.

Sep 99


Submit GSS-V2 Java service provider interface document to IESG for consideration as Proposed Standard.

Nov 99


Review status of ongoing active projects.


Request For Comments:







DASS - Distributed Authentication Security Service



Common Authentication Technology Overview



The Kerberos Network Authentication Service (V5)



The Kerberos Version 5 GSS-API Mechanism



The Simple Public-Key GSS-API Mechanism (SPKM)



FTP Security Extensions



The Simple and Protected GSS-API Negotiation Mechanism



Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API)



Generic Security Service Application Program Interface Version 2, Update 1



Generic Security Service API Version 2 : C-bindings



Encryption using KEA and SKIPJACK

Current Meeting Report

Minutes, Common Authentication Technology (CAT) WG, Adelaide IETF

Reported by John Linn, RSA Laboratories. Thanks to Cliff Neuman and Ken Hornstein for providing their notes and slides, which were used as inputs to preparation of these minutes.


The CAT WG met for one session in Adelaide, with 88 attendees.

John Linn opened the meeting with a general status overview, handing the floor to Jeff Schiller (MIT, Security AD) to present an organizational update. Jeff noted that the IETF today generally prefers tightly task-focused groups and that CAT's charter has been iteratively evolving for some time. He further observed that CAT's original focus was on the common GSS-API interface, rather than specifically on the Kerberos technology to which currently active standards-track CAT Internet-Drafts relate. It has been decided that the general CAT WG will go dormant, but with the mailing list to remain available as a forum to discuss progression of existing non-Kerberos CAT documents. Kerberos documents are to be transitioned to a new Kerberos WG, with the intent that its charter be established before the next (Pittsburgh) IETF and that an initial WG meeting without prior BOF session will take place there. Doug Engert (Argonne) has agreed to chair the group and will be doing so. Kerberos-related drafts that are ready for imminent Last-Call, in advance of establishment of the Kerberos WG, can still go to CAT.


Cliff Neuman (ISI) presented a status summary on Kerberos-Revisions. A new Internet-Draft version was recently issued. Significant remaining issues include: decision on the mandatory variants of 3DES, ticket extensions, and integration of the referrals draft. Additionally, some smaller and editorial issues must also be addressed, and a change summary relative to RFC-1510 must be prepared.

Updates since the last revision include integrated 3DES options, new registered types, and various edits, some of which require discussion. Cliff reported that the current 3DES description integrates all options in a single parameterized discussion, but that it references currently expired drafts and material must therefore be adapted from them. List discussion is needed to resolve whether or not to use the key derivation variant; Cliff reported that Microsoft and CyberSafe have tentatively agreed to accept key derivation, though that some skepticism was observed about its value. Cliff also reported that some coordination is pending with Microsoft on PAC usage. List discussion is required on the ticket extensions field, included in the current draft; Cliff intends to send a message to the list initiating debate on the benefits and drawbacks of its retention. Further discussion topics had been introduced on the list: whether policies on adding additional addresses to tickets should be specified, clarification on case sensitivity in names. During the Adelaide IETF week, Cliff's intent was to perform initial wordsmithing and to initiate the 3DES and ticket extensions discussions. He also anticipates referrals text pending from John Brezak (Microsoft), which will require further list discussion. Once at least the two major issues are resolved, WG Last-Call will be requested on Kerberos-Revisions and PKINIT; given the size of Kerberos-Revisions, John Linn suggested that an extended WG Last-Call period would be appropriate.

PKINIT is believed to have come to consensus among active participants, and to be ready for a parallel last call with Kerberos-Revisions. Recent changes include: name encoding, application of name constraints, and SignedData and EnvelopedData structure definitions. Regarding name encoding, the section on translation between X.500 names and Kerberos structures has been changed and expanded to specify the translation between general string and UTF8. A new structure corresponding to Kerberos PrincipalName, but with general string replaced by UTF8String, was defined to enable the use of UTF8 in the additional name field when Kerberos principal names are embedded in certificates. Rules were added for checking of a Kerberos PrincipalName against certificate chains which contain name constraints. The SignedData and EnvelopedData structure explanations have been reformatted and slightly edited for clarity. The old PKCS#7 data OID has been replaced by a pkdata OID under the Kerberos-PKINIT arc.


Ken Hornstein (NRL) presented discussion re the Kerberos DNS-Locate document (-02 draft). He reported that dns-locate is currently implemented in two different independent Kerberos implementations, is widely used, and appears to work well in simple usage. There had been significant contention on the CAT list about security concerns with host-to-realm mapping. Ken observed that the vulnerability exists only between realms which share a cross-realm relationship, and that it can exist in many common Kerberos implementations even without the use of DNS-based host-realm mapping; use of a different naming approach would be required to resolve this. Ken believes that the facility is useful and should remain within the draft as a feature that could be activated selectively. Following the discussion which has taken place, he also believes that more clarification is needed somewhere about the relation between Kerberos and DNS, and may consider a separate informational document for this purpose.


Cliff Neuman presented an update on the GAA drafts. It was noted that any request for progression of these documents would target Experimental status and would follow integration results with several applications. Recent GAA work has focused on implementation and changes needed for integration with particular applications. The new drafts define new generic conditions, which generate audit records when policies containing those conditions are encountered. Also, optional parameters are now translated to appropriate types by condition evaluation functions rather than being described by the separate gaa_options structure. The new C bindings have focused on a more "object-oriented" approach, inspired by the style of Hudson and Young's SSLeay, and with three classes of functions. The draft now uses a generic gaa_stack object (with implementation-specific structure) for representation of ordered lists rather than using a separate ordered list for each type of data.


Tom Yu (MIT) asked about futures for the Kerberos GSS mechanism. He stated that Microsoft and others are interested in squeezing 3DES into RFC-1964 rather than doing a general cryptosystem-independent scheme, and asked the attendees whether they wished to voice any objections to hacking into RFC-1964 rather than pursuing a wholly new approach. (Subsequent discussion observed that work on a near-term 3DES approach with RFC-1964 need not be mutually exclusive with parallel effort on a new approach.) It was noted that interoperability issues might arise if a single OID were used. Ted Ts'o (VA Linux) would like to see an analysis of what the failure cases and modes would be. Tom plans to circulate a more detailed proposal to the list.

A new version of PKCROSS is planned, but is currently blocked pending resolution on the Kerberos-Revisions ticket extensions question.

Ted Ts'o asked the meeting about continued interest in specification of a GSS adjunct interface for interactive credential acquisition, such as that which had been documented in his GSS Conversation Interface draft. Approximately three attendees indicated interest. To this point, GSS' scope has excluded asynchronous callbacks to applications and their associated users, partly for reasons of OS independence. Sam Hartman (FundsXpress) observed that SASL is an important client of GSS, and that it already has its own facilities for asynchronous callbacks to applications; given these facts, he considered that it would be inappropriate to define an incompatible facility at the GSS level. Ted indicated that he was not aware of API-level convergence among SASL providers, but others commented that such convergence was progressing.


None received.