2.6.3 Common Authentication Technology (cat)

NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.


John Linn <linn@world.std.com>

Security Area Director(s):

Jeffrey Schiller <jis@mit.edu>

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 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 96


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



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


Request For Comments:







Generic Security Service API : C-bindings



The Kerberos Network Authentication Service (V5)



DASS - Distributed Authentication Security Service



Common Authentication Technology Overview



The Kerberos Version 5 GSS-API Mechanism



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



Generic Security Service Application Program Interface, Version 2

Current Meeting Report

Minutes of the Common Authentication Technology Meeting

Reported by: John Linn (with thanks to Rich Graveman (Bellcore) for access to his notes from the session and to Cliff Neuman (ISI) for providing copies of his presentation slides in text form).

This version contains a few detail-level clarifications relative to the previous draft sent to the mailing list, per comments received from WG members.

The CAT WG met for one session at the Munich IETF.

I. Review of Ongoing Work Items: FTP Security

FTP Security (draft-ietf-cat-ftpsec-09) is in IESG hands and had been inadvertently delayed in its IESG consideration, but is reportedly on the agenda to be considered for Proposed Standard status at the next IESG conference call.

II. Review of Ongoing Work Items: GJSS-V2 and C Bindings

Re GSS-V2, the proposed approach is to integrate the RFC2078bis changes list into an updated GSS-V2 base Internet-Draft during September, and then (following a WG Last-Call period) to submit the resulting RFC2078bis and the GSS C bindings as an aligned set to the IESG, requesting their advancement to Proposed Standards; this proposed approach was acceptable to session attendees. No more than very minor changes to the C bindings are anticipated.

III. Review of Ongoing Work Items: SNEGO

Approximately six attendees indicated that they had reviewed draft-ietf-cat-snego-06; approximately 15 indicated familiarity with this or previous snego versions. It had been believed that draft-ietf-cat-snego-06 represented WG consensus for advancement, but Marc Horowitz (Cygnus) and Bill Sommerfeld (HP) indicated a position that draft-ietf-cat-snego-06 does not reflect previously established WG consensus in certain areas, and were to detail the specifics of their dissent to the WG list during the IETF meeting week. No other snego-related comments were indicated in the session. Follow-up discussion is underway on the mailing list.

IV. FTP and DSA, KEA/Skipjack

William Nace (NSA) presented a pair of recently distributed documents, concerning, respectively, FTP with DSA (draft-ietf-cat-ftpdsaauth-00-txt), and FTP with KEA/Skipjack algorithms (draft-ietf-cat-ftpkeaskj-00.txt). Other contributors include Peter Yee and Russ Housley. Given the status of KEA/Skipjack (currently classified), the document authors are targeting this document for informational status. Discussion within the session suggested informational status for the DSA document as well, but (given the fact of unconstrained DSA specification) the DSA document could be admissible for subsequent standards-track consideration by the WG. Approximately three attendees indicated familiarity with the drafts; a concern was indicated that the algorithms applied may constitute national-level solutions.

The DSA draft provides FIPS-196 authentication for FTP. Unilateral DSA signature-based authentication was discussed in the session, although support for both unilateral and mutual cases is defined within the specification. The KEA/Skipjack draft provides confidentiality for both the data and command streams; labels are also implemented. Encrypted data are base-64 encoded.


Brian Tung (ISI) presented and discussed the recently revised kerberos-pk-init and kerberos-pk-cross drafts. Brian noted that Kerberos open issues are being identified at http://gost.isi.edu/info/kerberos.


Approximately four attendees indicated they had read pk-init-04; approximately 15 were familiar with one or more pk-init versions. Document contributors include Ari Medvinsky and Matt Hur (CyberSafe), Jon Trostle (Novell), Brian Tung and Cliff Neuman (ISI), and John Wray (Digital). In draft-ietf-cat-kerberos-pk-init-04, a convention was added for translating between X.500 and Kerberos names. Mike Swift (Microsoft) questioned why base-64 encoding was applied in name translation rather than using the new name type being defined in 1510bis. Ted Ts'o (MIT) observed that the base-64 approach avoids the need to recognize X.500 semantics within Kerberos.

In pk-init-04, a client's realm comes from a certificate, not a KDC. A client's principal name also comes from a certificate. A KDC's principal name was added as an X.509 v3 attribute. Diffie-Hellman specification was imported from PKCS #3, specification was added for checksummed encryption, and more specific errors were defined.

Support within pk-init for SPEKE, an algorithm with which approximately three attendees indicated familiarity, had been proposed on the mailing list. Ted Ts'o believed that SPEKE was patent-pending, but terms were unknown; Cliff Neuman believed that patent or patent-pending status should not be a bar to consideration as long as an algorithm's implementation is not mandatory for conformance with the specification. Brian Tung is to continue discussion of SPEKE on the mailing list.

Mike Swift observed that Microsoft's CAPI supports PKCS formats rather than bare-level public-key encryption, and would like to be able to support pk-init functions with PKCS-level objects. Ted Ts'o agreed that this suggestion appeared reasonable, noting the broad existing base of code supporting PKCS formats. Brian Tung will raise this issue to the list for further discussion. A suggestion was made that use of X.509 AltSubjectName be considered.


Brian Tung described draft-ietf-cat-kerberos-pk-cross-02 as including minor changes relative to its predecessor. Approximately two attendees indicated that they had read pk-cross-02; approximately seven indicated familiarity with one or more pk-cross revisions. In pk-cross-02, the remote realm now determines the lifetime of a shared key. Matt Hur has suggested using pk-init to do pk-cross, which would be a major change. Mike Swift noted that Microsoft was evaluating usage of DNS as a means to locate KDCs; this was considered to be a form of existing practice that may warrant codification in RFC1510bis. Mike Swift also reiterated his recommendation, as made relevant to pk-init, to allow public-key operations to be performed using PKCS objects.


Cliff Neuman (ISI) discussed status and issues relative to the Kerberos RFC1510bis document, draft-ietf-cat-kerberos-revisions-00. Approximately four attendees indicated that they had reviewed this draft.

Changes and issues had previously been summarized to the CAT list. It was noted in discussion that the currently pending issues list includes the addition of key derivation procedures for 3DES support.

Document-related comments were solicited, to krb-protocol@mit.edu for protocol-related issues and via http://gost.isi.edu/info/kerberos (as also used for pk-init, pk-cross, and pktapp). An HTML/SGML version is in progress, targeted for completion by 1 September; its content will correspond to a new I-D (kerberos-revisions-01) to be submitted. As revisions of the HTML versions proceed, corresponding I-Ds will also be issued and will remain authoritative.

Major changes considered since the kerberos-revisions-00 I-D, and discussed at the session, are:

1. Authorization data field: Elements are of type AuthorizationData (new terminology). New element types include: kdc-issued (checksummed with application server's key, vouched for by the KDC of that application server's realm), intended-for-server and intended-for-application-class (identifying targets or sets thereof for which a ticket is intended), if-relevant, and Boolean combinations of authorization elements ("or" is currently proposed; "and" was considered appropriate as well).
2. If a kdc-issued element occurs in an inter-realm environment, a receiving KDC reads and (if acceptable) reissues the element; it is not passed through without reissuance and, were a passed-through element to occur, that element would be ignored. Each of the intended-for-server, intended-for-application-class and if-relevant attribute types carries a sequence of elements. If intended-for-server or intended-for-application-class attributes are not understood at a targeted recipient, their enclosing ticket is to be rejected; if received elsewhere, they may be ignored. If if-relevant attributes are not understood at a targeted recipient, they may be ignored. In the interests of simplicity, and without perceived loss of needed function, it was agreed in discussion that kdc-issued should be limited to appear at the top nesting level only, and should not nest recursively.
3. Backwards compatibility with existing code incapable of recognizing these newly-defined elements was considered important; Cliff Neuman is to propose text to the mailing list discussing the circumstances under which these elements should be included. One suggestion was that they be included at the level of a ticket element.
4. Extensions field to ticket: This is an optional sequence, allowing additional data to be linked to the ticket so that it follows the ticket throughout the system. It is located in a ticket's cleartext portion at the end of the ticket, is typed opaque, is linked from within the authorization data field, and contains a flag as to whether it is OK to be removed. It can be used for PK-CROSS to distribute the inter-realm key, or can be used to distribute authorization data that is integrity protected but not confidential, plaintext ticket data, or accompanying authorization credentials. Placement of the extension field in the ticket's cleartext portion allows unnecessary encryption of ancillary data to be avoided.
5. Optional client version in pre-auth: This identifies the version of kinit, in a manner considered analogous to an HTTP version string. The intended concept is to use this for backward compatibility when changes are made. These numbers are not registered and vendor dependent; vendors or users of this field are admonished to pick version identifiers unlikely to conflict with those of other vendors. No corresponding server version identifier is provided, so as not to advertise known and exploitable bugs.

IX. RFC2078BIS, RFC1964 Issues

John Linn led discussion on some specific issues related to RFC2078bis and RFC1964. Specific items cited:

1. Re sequence number setup in RFC1964, John Wray's working proposal for the context acceptor to use the initiator's ISN in the single-hop case was accepted (recognizing that a separate reflection indicator is included in the protocol).
2. Re gss_display_status and CONTINUE_NEEDED: some clarification was desired as to whether these can be used together or not. Some existing implementations return CONTINUE_NEEDED when iterating through successive messages returned from gss_display_status, but this had not been contemplated in RFC-2078. The sense of the discussion was that CONTINUE_NEEDED should be returned only by gss_init_sec_context and gss_accept_sec_context; this intent (along with commentary on the residual portability issue) should be cited in RFC-2078bis and defensive callers should ignore CONTINUE_NEEDED if returned by calls other than gss_init_sec_context and gss_accept_sec_context.
3. If a name of the type GSS_C_NT_EXPORT_NAME is imported with an unrecognized mechanism (OID) in the framing defined by Section 3.2, GSS_S_BAD_MECH is to be returned."
4. RFC-2078 contains MIT arc OIDs for some, but not all, of the generic name types; this was considered benign and the sense of the discussion was to retain these OIDs to avoid backward compatibility issues. For the case of host-based service, where an IANA arc OID had been assigned for use in preference to its predecessor MIT arc OID, it was recommended that both OIDs be accepted with equivalent effect but that the MIT arc OID be emitted on output; the sense of discussion was to reverse the prior recommendation preferring the IANA arc OID over the MIT arc OID representing the same type, in order to avoid backward compatibility issues with existing implementations.
5. RFC-2078bis needs (per discussion re snego) to add facilities for informatory conf_req, integ_req inputs to gss_init_sec_context.

The conjunction of supplementary info bits and non-zero routine errors was discussed briefly. The goal is to tighten up the list of possible cases. This topic was deferred to discussion on the list.

X. RFC1964 Extensions

Mike Swift solicited interest in two possible areas of extension to RFC-1964; user-user authentication and initial authentication via a dial-up access server.

Mike noted that user-user authentication would be useful for DCOM, and suggested support for Kerberos user-user authentication as a submechanism within RFC-1964. Marc Horowitz believed that it would be more appropriately supported as a separate mechanism with its own OID; snego could be used to select between RFC-1964 Kerberos and a user-user mechanism. Generic resolution of name discovery for the user-user environment was believed to be a difficult issue, but there appeared to be interest in investigating and potentially drafting a specification for user-user authentication support.

Mike also solicited interest in specification of initial authentication via a dial-up server (as in pktapp), where an initial request is forwarded through an access server. Ted Ts'o commented that Derek Atkins' Charon thesis had addressed essentially this problem some years previously.

XI. Other Discussion

Bengt Ackzell (Generic Systems) noted that, per the Memphis CAT minutes, IDUP had been planned for placement into WG Last Call following the Munich meeting if no comments were pending. Recent IDUP on-list discussion has been quiet, the base specification has not been recently revised, and issuance of corresponding C bindings remains pending. Upon further review, it appeared that further revision or on-list discussion of pending comments was needed before proceeding.


None Received

Attendees List

go to list

Previous PageNext Page