2.6.1 Common Authentication Technology (cat)

NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 11-Jan-99


John Linn <linn@rsa.com>

Security Area Director(s):

Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortel.ca>

Security Area Advisor:

Jeffrey Schiller <jis@mit.edu>

Mailing Lists:

General Discussion:cat-ietf@mit.edu
To Subscribe: cat-ietf-request@mit.edu
Archive: ftp://bitsy.mit.edu/cat-ietf/archive/

Description of Working Group:

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:



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.

Apr 96


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

Jun 96


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

Jun 97


Submit revised version of RFC1510 (Kerberos) to IESG for consideration as a Draft Standard.

Jun 97


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

Jun 97


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

Jun 97


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.

Aug 97


Review status of WG Internet-Drafts and plan follow-on activities.


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 list members: these minutes match the draft set as sent to the list on 24 March, with an additional comment added in the summary of the low-infrastructure minutes straw poll to note (as discussed in the session) that it was OK for participants to support multiple options.]

Minutes, Common Authentication Technology (CAT) WG, Minneapolis IETF, reported by John Linn (RSA Laboratories).

The CAT-WG met for one 2.25 hour session at the Minneapolis IETF, with 114 attendees. Regarding document actions, John Linn reported that the GSS-V2 and C bindings drafts have been forwarded to the IESG, with a request that they be considered for Proposed Standard status. Major discussion topics at the meeting included Kerberos Public-Key Initial Authentication (PKINIT), other Kerberos drafts, GSS Java bindings, and GSS Low-Infrastructure mechanisms.

Kerberos Public-Key Initial Authentication (PKINIT):

Following introductory comments by Brian Tung (ISI), Matt Hur (CyberSafe) led discussion of the Kerberos-PKINIT document. Current draft changes and pending issues were reviewed and discussed. Among other points, a follow-up draft will adopt use of CMS constructs to define the request from client to KDC as well as the KDC's response, and means for accommodating key usage fields in certificates will be considered.

Other PKINIT issues were also discussed. John Brezak (Microsoft) had commented that PKINIT required support for too many options, but candidate simplifications were not indicated. Brian Tung agreed to obtain clarification, and to inform the list. As currently specified, PKINIT error messages collide with the space reserved for user-user authentication codes; this will be addressed in the Kerberos-Revisions document. There's an ambiguity as to which error message to use if a server/KDC name in the PKAuthenticator is wrong. PKINIT clients must specify supported encryption types to the KDC. It was suggested that the Kerberos enctype definition could be changed (from its current SEQUENCE OF INTEGER), but was noted that viable options exist which don't need changes to Kerberos-Revisions, just to Assigned Numbers. The working conclusion was to map the PKINIT-supported encryption types into Kerberos enctype values without restructuring their format.

The following changes had been incorporated in the most recent PKINIT draft: Removed digital signature and private key storage options, modified server response definition to incorporate CMS by reference, and added various clarifications. Additional planned changes include removal of references to PKCS#6, changing "Certificate" type to "PKInitCertificate", and alignment of wording and client-KDC request structure with CMS. Sam Hartman (FundsXpress) proposed that the KDC-client reply should have a CMS EnvelopedData containing a SignedData, and plans to contribute specific text for this proposal; as a working position, use of this approach was accepted. A NULL method-type is to be added for the method-data structure within a PKINIT error message, and the KDC is to return RB_APP_ERR_MODIFIED when a signature does not verify.

Denis Pinkas (Bull) commented that PKINIT's introduction needs modification to reflect Diffie-Hellman as mandatory and RSA as optional, and suggested also including a facility for signing a users' key independently of a certificate. He also indicated concern about the use of a single certificate for signing and encrypting, wanting separate certificates to be used in order to allow segregation by key usage. There was consensus among attendees to allow segregated support, but a specific proposal to the list is required in order to define the approach.

Kerberos-Revisions and related drafts:

Cliff Neuman (ISI) led discussion of various changes and issues regarding Kerberos-Revisions (RFC-1510 successor). He indicated his intent to send a summary of outstanding issues and current proposals to the WG list during the IETF week as a basis for resolution, confirmation via straw poll, and preparation of a follow-up draft, in the hope that the follow-up draft could be suitable for WG Last-Call. He reported that revisions were in progress on integration of enctype specifications, numbering of error messages, tightening definitions for optional and default values, on direction bits if addresses are omitted, and on appropriate processing for authorization data elements which are not understood. Identified open issues: how to deal with added fields in KRB-ERROR, ticket extensions, optional KRB-CRED fields, encryption types, and the general approach for interoperability in the face of new protocol elements.

The concern with encryption types is that CMS usage requires the KDC to know which algorithms a given client supports, within a potentially extensible set. Cliff proposed that algorithms be identified for this version within the supported e-types of the KDC-REQ message rather than in a new pa-data field; these types are integers (not OIDs), so Kerberos values must be registered for algorithms which are to be used. Regarding support for additional or changed fields, it appeared desirable to identify all items needing change at one time, and to require compliant implementations (as of a certain date) to process new fields appropriately. New fields would be used only after a transition period, or with knowledge that the peer can support them. Ted Ts'o (MIT) argued that any new support requirements should become active as of the specification's effective date, rather than at a later point; Sam Hartman pointed out that it might be appropriate to associate a tier of support requirements with support for new cryptoalgorithms.

Ted Ts'o recommended that ciphersuite constructs be incorporated, believing that their initial omission from Kerberos has had unfortunate results. This also affects the Kerberos GSS mechanism-2 document, and Tom Yu (MIT) is to frame the issue within subsequent Kerberos-Revisions discussion. Marc Horowitz (Stonecast) solicited comments on his recent draft on Diffie-Hellman usage in Kerberos.


Cliff Neuman presented brief status information on the GAA-API activity; revised drafts are planned for the Oslo IETF reflecting ongoing experience in application of GAA constructs. ISI has been working with Xerox on GAA-CORBA integration, and with the GLOBUS project, and seeks more groups to work with. Work on a reference implementation has been pursued, including integration with X.500/X.509 and SSL. Information is available at http://gost.isi.edu/info/gaaapi, which will be updated in the next few weeks. Marc Horowitz (Stonecast) asked whether there was any relation between GAA and the IETF General Area's AAA and Policy groups. There was no formal conclusion, but Sam Hartman noted that he intends to act as an informal liaison to AAA's authentication group.

GSS Java Bindings:

Extended discussion took place on the GSS Java bindings, led by Mayank Upadhyay (Sun). The central question at issue was use of concrete classes vs. Java interfaces. Interfaces provide greatest power and flexibility, but their use was considered more complex and less intuitive to some Java programmers. Since GSS is already considered complex in some circles, it was considered undesirable to mandate more additional complexity than necessary for use via JGSS. Support for usage of multiple mechanisms within a single invocation of an application program was considered to be an important goal (e.g., to support applications like NFS). The conclusion, to be reflected in a revised draft, was to incorporate a factory approach with Java interfaces for flexibility, but to provide a simple-to-use shim that would instantiate classes corresponding to those interfaces. By analogy, it was noted that factories and interfaces are also used within JCAPI. Using the factory approach, a given application can access multiple mechanisms within one or more coresident JGSS implementations. Alternately, an application can choose to bind to a single JGSS implementation by using CLASSPATH rather than factories.

A separately defined service provider (SPI) layer, whose definition may be pursued later, would enable individually developed SPI provider implementations to be accessed through a single higher-layer JGSS implementation. While such an SPI would be similar to JGSS, it was recognized that it wouldn't be identical, considering, e.g., the fact that credentials can be multi-mechanism objects. Consistent with a goal expressed by Jeff Schiller (MIT), progress on a higher-level JGSS specification is not to depend on an SPI definition. An SPI approach would avoid the need for applications consuming services provided by multiple lower-layer JGSS implementations to track the correspondence among mechanisms, their providers, and associated objects, thereby simplifying application access to a dynamically-variable set of available mechanisms.

A specific issue arises for use of applets. An applet developer may wish to access a custom JGSS implementation via standard ("org.ietf.JGSS") class names, but an existing JGSS implementation on the applet's platform would be accessed instead. As an interim approach to this problem, Mayank proposed that the applet could invoke the custom implementation via another name, which the applet's code would import. Eventually, a custom implementation could be layered under SPI, downloaded, and accessed through the browser platform's SPI-layered JGSS.

Mayank and Jack Kabat (ValiCert) will continue working on the base JGSS document, but will not also be working on an SPI definition. It was noted that Sun had donated C language GSS-SPI code to MIT, but Ted Ts'o reported that he found the code unreliable and hasn't been working actively with it. It's included in the Kerberos V5 distribution but is currently disabled; absent inclusion of another mechanism besides Kerberos, the motivation to debug its use was limited. The C GSS-SPI is also included in Solaris, enabling selection between Kerberos and a dummy mechanism.

GSS Low-Infrastructure Mechanisms:

Extended discussion took place on the topic of low-infrastructure GSS mechanisms. Concern was expressed about possible duplication with SASL-level mechanisms, and John Myers (Netscape) is to send a draft concerning GSS integration under SASL for consideration by the CAT-WG. It appears that different communities and types of applications wish to consume services via GSS or via SASL, even though underlying mechanisms may overlap. It was recognized that more communication is needed between SASL and GSS proponents, and some SASL concerns (e.g., lack of defined service interface) were briefly cited. Within the session, two specific GSS mechanism proposals, GSS-Easy and LIPKEY, were discussed.

Denis Pinkas (Bull) led discussion about the GSS-Easy proposal, which about 10 attendees indicated that they had read. The GSS-Easy mechanism requires no public-key infrastructure, and performs passphrase-derived exchanges using one-way functions (OWFs); a Passkey is derived through N iterations of an OWF, where a large N provides bandwidth limiting against guessing attacks. A passphrase change facility is included. Unilateral and mutual authentication are supported. Loosely synchronized clocks are assumed between initiator and target. Per the draft, GSS-Easy's proposed message protection approach is OWF-based rather than being layered on existing symmetric algorithms. This approach was controversial: while OWF-based encryption may comprise a valuable topic for research, the sense of discussion opposed pursuing it at this time as a basis for standardization. Sam Hartman indicated concern about dependencies on hash algorithm properties, observing in particular that it wasn't clear whether SHA had been analyzed for correct properties if used within an encryption function. Paul Leach (Microsoft) suggested that at least 2 ciphersuites be incorporated. Per list discussion, Denis plans to remove ASN.1 framing around the confounder. More generally, use of direct octet encoding was preferred to ASN.1 representation (by an approximately 2:1 margin), but most proponents of direct encoding would not reject an approach on the basis of ASN usage.

Mike Eisler (of Sun's NFS group) led discussion on the Low-Infrastructure Public-Key (LIPKEY) proposal. About 5 attendees indicated that they had read the draft. The LIPKEY mechanism adapts SPKM's SPKM-1 unilateral mode for an environment where servers are registered with public-key certificates, but where client users authenticate with passwords. Mike cited several LIPKEY priorities. Familiarity breeds acceptance (people will adopt what they understand and are used to). Server authentication in Internet environments was considered more important than client authentication. Reduced client impact is important since there are more clients than servers. Almost all OSs have some form of native password support, and this can and should be leveraged without user reregistration. LIPKEY's form is like TLS with passwords, so uses a level of infrastructure that has achieved a status of common practice. As a result, it may be more easily grasped and accepted than Kerberos, though can be suitable for application protocols (e.g., UDP-based applications, RPC) that cannot or will not use TLS. LIPKEY's usage of the SPKM context establishment request varies from RFC-2025, since certificate acquisition is assumed to take place in-band; it may be appropriate to describe this variant usage as a new SPKM-3 mode. Mike noted his neutrality about the general issue of encoding conventions, but does not propose to redefine SPKM's existing ASN.1 structures to use different encoding. It was noted that LIPKEY usage requires that a user's password be obtained and accessible via a user's credentials.

At the end of the session, a straw poll of attendees was taken to determine interest in pursuing standardization of various low-infrastructure GSS-API alternatives. Attendees were allowed to express support for multiple options. Greatest interest was apparent in LIPKEY (19 attendees recorded), followed by GSS-Easy (12 attendees), and various forms of digest authentication (10 attendees). One attendee indicated interest in pursuing EKE/SPEKE/SRP methods. No attendees indicated opposition to pursuing standardization of one or more low-infrastructure mechanism candidates within the GSS framework.


The GSS-API Easy Mechanism
Java GSS-API: Concrete Classes or Interfaces?
LIPKEY: A Lower Infrastructure Public Key Mechanism