2.6.1 Common Authentication Technology (cat)

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Sep-99


John Linn <linn@rsa.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:







The Kerberos Network Authentication Service (V5)



DASS - Distributed Authentication Security Service



Common Authentication Technology Overview



Generic Security Service API : C-bindings



The Kerberos Version 5 GSS-API Mechanism



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



Generic Security Service Application Program Interface, Version 2



FTP Security Extensions



The Simple and Protected GSS-API Negotiation Mechanism



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

Current Meeting Report

CAT WG Minutes, DC IETF, 8 November 1999

Reported by John Linn (RSA Laboratories).


The CAT WG met for one session at the November 1999 IETF, with 82 attendees. The most extensive discussion was devoted to Java GSS bindings, and particularly to the question of the GSSManager facility. GSSManager is to be changed from a concrete class to an abstract class. A subgroup discussion is to propose a conclusion to an issue on management methods, after which point production of a revised draft for WG Last-Call is anticipated. The second major topic area was Kerberos documents, including Kerberos-Revisions (RFC-1510bis), Kerberos PK-INIT, and Kerberos DNS-based server location. Revisions to these documents are in progress or planned, after which point WG Last-Calls are anticipated. Additional topics, briefly discussed, included a GSS Conversation Function, GSS-Easy mechanism, and a proposal for a GSS mechanism based on SSL/TLS tokens.


Michael Smith (TIAA-CREF) has been working on a Java GSS service provider interface (SPI). He recommends that GSSManager be made an interface, rather than a concrete class as represented within the current draft. Further, he would prefer to remove the limited mechanism management method (setProvider) which is currently included in the high-level GSS-Java document, instead deferring this topic to a shim SPI specification. He anticipates two kinds of JGSS implementations, one shim-based, one monolithic. Michael cited several reasons for making GSSManager an interface: if implemented as a class, benefits of multiple inheritance would be lost; a locally installed implementation could interfere with other subclassing implementations; and implementation as a class could provide a possible hook for imposition of crypto controls. He commented that a class implementation would have the effect of causing IETF to include a separate implementation by reference within an API specification, which appeared anomalous. He believed that the problem of locating implementations is relatively easy and can be accommodated within an interface paradigm; further, he argued that this problem shouldn't properly be handled within the language binding spec.

Mayank Upadhyay (Sun) asked how local resource discovery would be accommodated within an interface model. Use of a system property had been suggested, but this doesn't work for applets. Alternately, a GSSFinder class could be defined and implemented outside the GSS implementation per se. Ted Ts'o (VA Linux) hesitated to depend on completion of a shim SPI specification for management facilities; he considered it critical to find the default implementation using a quick, easy, and mandatory-to-implement means, and doesn't think it's bad for GSSManager to be that concrete class. While it would be possible for this to be defined in a separate document, this approach would be procedurally inconvenient. Michael Smith was hesitant to build in a dependency on the use of providers, and asked whether a GSSFinder class would need to be provided by a GSS implementer or elsewhere in the environment. Paul Leach (Microsoft) asked whether the current GSSManager class definition contains a mixture of independent functions that should be decoupled from one another; Mayank thought that this was not the case, and offered to send follow-up mail to support this assertion.

Jack Kabat (ValiCert) summarized the changes in the -03 draft of the JGSS document, and identified a list of discussion items. About 5 attendees indicated active interest in the ongoing discussion. Updates include the following: there is now an instantiable GSSManager class (allowing customization of the manager, and making changes instance-wide rather than JVM-wide); concrete class wrappers have been removed from GSSName, GSSCredential, and GSSContext; GSSFactory interface and support details have been removed and deferred to the SPI specification. More updates: minor status treatment in MessageProp, removed dependency on java.security.Principal (since the Principal interface isn't always available), general package rename to org.ietf.jgss, and updated samples.

Mayank led further discussion of the question of GSSManager as concrete class vs. interface. He believes that simplicity to users is paramount, and noted that use of a class provides something well-defined for apps to reference. As an alternative to a concrete class, Joe Salowey (WRQ) had suggested making GSSManager an abstract, well-known class with one static getInstance. This would avoid the prospect of a GSSManager implementation restricting extensibility. Ted Ts'o observed that use of abstract classes to override the default implementation might complicate administration; Mayank pointed out that use of an SPI-supporting implementation would be a preferable way of accomplishing such overrides. It was also observed that use of providers might complicate the extensibility available through use of an abstract class. The general sense of the room was that, if a class is to be used for GSSManager, an abstract class is preferable to a concrete class. Michael Smith indicated that he could accept use of an abstract class rather than an interface, but reiterated his request that management functions be removed from the high-level specification.

Jack Kabat led discussion on the question of allowing applications to pass and accept object-level representations of tokens. Jack objected to this proposal for several reasons: non-portability, complexity of required object registration scheme, and the observation that (unlike prior GSS), it would make application protocol logic part of JGSS. Michael Smith noted that byte array representations are a special case and would always be supported, with other supplementary representations optional. He proposed to add new methods that would allow applications to determine whether/what supplementary formats are supported. The supplementary representations were intended for use with legacy protocols and for applications that are tied to particular authentication protocols (e.g., digest); he found them particularly useful in a servlet environment where, e.g., http knowledge can reasonably be assumed. Marc Horowitz (Stonecast) observed that it can't reasonably be assumed that GSS can support applications and protocols which were not designed for GSS. In a straw poll, approximately 3 attendees indicated their support for the supplementary, object-level approach while approximately 5 followers of Java bindings development wished to exclude the approach, so consensus for its inclusion was not apparent.

The final Java topic discussed concerned JGSS provider management methods, which Michael Smith had requested be removed from the JGSS specification. Only two methods now remain, and Jack Kabat believes that they're necessary. While these functions could be accomplished within an application-specific class, a facility would then be required to locate that class. It was left to an ad hoc Java group to discuss the issue further and propose a resolution to the mailing list, in order that the JGSS specification can proceed towards WG Last-Call. Ted Ts'o commented that prior agreement had been reached to defer SPI issues for later consideration, but Paul Leach reiterated a prior concern that SPI-related concerns be adequately addressed within the JGSS document. Mayank indicated his belief that the SPI-JGSS dependencies have been suitably constrained.


Cliff Neuman (ISI) led discussion on Kerberos topics, beginning with a summary of the relationships among the large number of currently posted drafts related to Kerberos. He considered DNS-Locate and Set Passwd drafts to be independent of Kerberos-Revisions (1510bis) and free to proceed; they will be cited in 1510bis if they have advanced at the time of 1510bis' advancement, but no dependencies link in either direction between 1510bis and these documents. He believes that Extra TGT should remain a separate spec, not to be included in 1510bis although extending the basic Kerberos protocol. He described IAKERB as a separate spec, extending basic Kerberos protocols and dependent on a minor loosening in the base spec, which may be specified either in 1510bis or IAKERB; as a result, IAKERB and 1510bis should proceed in parallel. PKINIT depends on and extends 1510bis, and should move along with 1510bis. PKCROSS and PKTAPP have been on hold pending PKINIT, on which they depend, and will not proceed before PKINIT is finalized.

Regarding PKINIT, confirmation was requested that the comments made by John Linn, Denis Pinkas, and Paul Leach against an earlier draft have been suitably addressed. The final known issue concerns transited field processing, as has been discussed on the WG list. Cliff strongly believes that this data needs to be encoded, but Microsoft had noted interoperability problems with the proposed approach and old Kerberos realms. It would be useful to include clarifying examples in the text. Cliff is to circulate proposed changes among the other draft authors, and then send those proposed changes to the WG list. Cliff reported that one of his students has a reference implementation of the current PKINIT draft, which will be fed to MIT.

Regarding 1510bis, Cliff reported that a recent focus of activity has been on 3DES and SHA1 variants. Cliff proposed that two variants be defined, with and without key derivation. Ted Ts'o believed that this would be an unfortunate result. Cliff's preference is that both variants be specified, with a subsequent group vote to determine which will be specified as mandatory. Some backward compatibility questions exist relative to existing code, which was shipped before definitions became stable. The last Internet-Draft version was issued before the Oslo meeting; revisions have been made to the live working document, which was not yet finalized as of the WG session, but final changes were to be integrated during the IETF week.

David Miller (CyberSafe) plans to submit a draft concerning use of 3DES in Kerberos V5 and GSS after the meeting, which will be co-authored by CyberSafe and Microsoft. This draft will address both Kerberos V5 and GSS layers, in the interests of achieving interoperable 3DES. Tentatively, it is to propose three 3DES Encryption Types: 2 mandatory SHA types and 1 optional MD5 type, but the set to be specified may be revisited on the mailing list. GSS issues were identified: new flags are desired to reflect crypto strength at per-context level; new QOPs are to be defined; token formats need to be adjusted to reconcile limitations of the checksum algorithm structure as defined in RFC-1964. It was noted that Tom Yu (MIT) had been working on a successor to RFC-1964, which would be represented with a new OID, and may be undertaking a new revision of this document.

KRB-DNS-SRV (Jeffrey Altman (Columbia University)): About 10-15 attendees indicated familiarity with this activity, and all recommend advancing on standards track. Jeff considers its greatest value to be avoidance of the need for preconfiguration of data in clients. The most recent draft adds a _kpasswd name. The approach is currently supported in Kerberos implementations including MIT, Heimdal, and Windows 2000 RC2. A recently-arising issue: should a workaround for KDB propagation delays be included in the draft? Sense of room: yes. Following integration of this change, the draft may be ready for WG Last-Call.


Cliff Neuman reported that no recent updates have been made to the GAA specification. Currently-ongoing GAA activities include Globus integration, policies for a group signature authority, and XML policy representation.

Denis Pinkas (Bull) presented a brief update on the GSS-Easy mechanism proposal, currently represented in draft-ietf-cat-gsseasy-01. The primary change in this version makes it unnecessary for the server to know a shared PassPhrase with the client. A subsequent change is anticipated to prevent server-side dictionary attacks.

Ted Ts'o (VA Linux) led brief discussion on the GSS Conversation Function draft, which was issued a few weeks before the meeting. He observes that many prospective mechanisms (e.g., IAKERB if realized at the GSS level, GSS-Easy) need user input at context establishment. The draft proposes a variant of GSS_acquire_cred which takes a pointer to a callback function. The approach is similar to Pluggable Authentication Modules (PAM), is suitable for TTY or GUI interfaces, and doesn't currently deal with internationalization issues. Iterated, multi-step user interaction rituals can be supported. Approximately 5 attendees indicated that they had read the draft, and approximately 10 indicated interest in pursuing work in this area as a standards track item, with none indicating opposition.

Frank Siebenlist (Dascom) led brief discussion of a GSS-SSL mechanism concept. Preparation of a draft is in progress. The goal is to adapt SSL/TLS tokens and runtime support to provide a transport-independent, GSS-based public-key mechanism. Frank does not perceive SPKM as having broad support, and therefore wishes to leverage the broad SSL/TLS base. It was reported that Argonne Labs (Globus) has a reference implementation, based on SSLeay and due to Doug Engert and Steve Tuecke, and that similar functionality was implemented by Microsoft within Windows 2000. Paul Leach confirmed that Microsoft supports SSL under its GSS variant (SSPI), but specifications therefor have not been available and interoperability with the Argonne implementation hasn't been tested. At a high level, the SSL/TLS handshake corresponds to GSS's Init and Accept sec context calls, and SSL/TLS application data to GSS's Wrap and Unwrap calls. At lower levels, issues arise: SSL/TLS framing is arbitrary, while a GSS token corresponds to a delimited application message; token format issues also need to be considered. SSL/TLS doesn't have GSS naming constructs, but Frank doesn't consider this area a major problem. Big misfits between GSS and SSL/TLS: SSL/TLS can mix control frames with application data, GSS doesn't support session resumption. Frank's proposed next steps were as follows: standardize through IETF, seek buy-in from SSL vendors and implementers, contribute Argonne implementation to OpenSSL, solicit comments. Progression of the LIPKEY mechanism to WG Last-Call is pending on a revision to the document, and possibly also on prototyping work.

Approximately 25 attendees indicated that they would likely attend a CAT session if held at the Adelaide IETF in March 2000.


GSS-Mechanism based on SSL/TLS protocol