2.6.3 Common Authentication Technology (cat)

NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 23-Jul-98


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:






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



FTP Security Extensions

Current Meeting Report

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


The CAT WG met for one session at the Chicago IETF, with approximately 130
attendees. The SNEGO document, which has been through IETF Last-Call, will be
issued for ballot within the IESG shortly. Final alignment changes to RFC2078bis and
the GSS-V2 C bindings were agreed, and versions of this pair of documents are to be
submitted to the IESG following the meeting to be considered for advancement to
Proposed Standards. The Kerberos PKINIT and PKCROSS drafts were discussed. A
revised version of PKINIT is to be issued after the meeting reflecting evaluation of a
patent issue concerning KDC private key storage and (consistent with the Munich Doctrine)
removal of the specified requirement for mandatory (vs. optional) RSA support. Following
these changes, the PKINIT draft is to be considered for WG Last-Call. A revised version
of the Kerberos-Revisions document is expected soon after the meeting week for working
group review, reflecting results of a focus group discussion scheduled after the CAT
session. The recently reactivated Kerberos-Passwords draft was presented briefly. Two
prospective new work areas were presented: significant attendee interest appeared in a
proposal on GSS Java bindings and moderate interest appeared in authorization interface
proposals (GAA); ongoing review and discussion of these documents was solicited on the
WG mailing list.


According to information available at the meeting, the SNEGO draft is to be balloted
within the IESG shortly. The IDUP draft was in discussion within the IESG, with no
status to be reported.

The current WG mailing list administrators at Stanford University were thanked for their
efforts and support; list-targeted traffic can now be addressed directly to
ietf-cat-wg@lists.stanford.edu with Majordomo list management facilities accessible at
ietf-cat-wg-request@lists.stanford.edu. (The existing addresses at mit.edu now
autoforward to these addresses.)


John Linn led brief discussion on these documents (which have already been through
WG Last-Calls), in advance of their planned submission to the IESG. Two specific
changes, resulting from alignment review between the documents, were agreed. It was
accepted (despite a recognized backward incompatibility, which will be documented)
that integ_req_flag and conf_req_flag inputs to GSS_Init_sec_context() will operate
as currently specified in RFC2078bis. Per-message tokens are not to be emitted along
with an error major_status value. Security considerations will be added to the
documents, including: the fact that no security is provided by GSS itself rather than
the underlying mechanism, that applications must check status indicators to be cognizant
of what security services are being provided, and concerning the security implications
of context transfer. A revised pair of RFC2078bis and C bindings documents, reflecting
these edits, is to be prepared and submitted to the IESG following the meeting.


Cliff Neuman (ISI) summarized status of the Kerberos-Revisions (RFC1510bis) draft,
indicating a desire to clean up final topics during the meeting week. An informal session
was scheduled later during the week for this purpose, with issues to include the following:

- ticket extensions and how they should be included (point: whether old
implementations would drop them or treat them incompatibly or inappropriately),
- authorization data for required ticket extensions
- triple-DES string-to-key transform to achieve MIT compatibility
- possible mandated support for TCP transport
- PKINIT-driven issue re mapping of X.509 names to principals
- name referrals (topic of a draft authored by Mike Swift).

Approximately 10 WG attendees indicated interest in attending this informal session,
and Cliff is to circulate notes from that discussion to the WG mailing list.


Ken Hornstein (NRL) presented a brief discussion on the kerberos-passwords draft
("Integrating Single-Use Authentication Mechanisms with Kerberos"), which defines
means for using challenge-response and authenticator token technologies with Kerberos
preauthentication. Ken had recently revised and reissued this document, which was
originally co-authored by Cliff Neuman, Glen Zorn, and Jonathan Trostle. Ken observed
that there are several deployed realms with significant user sets making use of this
protocol. Approximately 14 attendees indicated interest in progressing the document.
Marc Horowitz (Stonecast) pointed out that the currently-specified checksumming
procedure for PA-SAM-CHALLENGE is anomalous, as its coverage is unclear and
its method implies violation of ASN.1 conventions. It was proposed that a new ASN.1
type be defined in order to make checksum computation more straightforward.


Brian Tung (ISI) led discussion on the Kerberos PKINIT and PKCROSS drafts.

New aspects in PKINIT include:

- PKCS-7/CMS have been copied in by value, with appropriate algorithm
identifiers added
- servers now see the same name for both PKINIT and non-PKINIT clients
- added text on key requirements.

Issues to resolve:

- patent issue on the optional KDC private key storage facility; reportedly, Charlie
Kaufman (Iris) is to attempt to identify a Compaq contact who would be able to
address intellectual property concerns regarding the relevant patent, originally
issued to Digital Equipment Corporation
- possibly mandating support for signature-only users (intent is already to make it
mandatory for PKINIT KDCs). Denis Pinkas (Bull) noted that signature-only usage
is important to contemplated DCE usage of PKINIT in OpenGroup.
- Password changing

The removal of a mandatory requirement for RSA support, for conformance with the
Munich Doctrine, was also discussed. It was noted that existing implementations have
been RSA-based. Brian proposed that Diffie-Hellman be made mandatory, RSA
optional; this proposal was carried unanimously within a straw poll of about 10 attendees.

Frank Siebenlist (Dascom) noted that he was working on an X/Open (Open Group)
activity related to PKINIT, needed access to data on ongoing revision plans, and was
concerned about the limited amount of PKINIT discussion on the public WG mailing
list. Denis Pinkas noted that Open Group discussion was scheduled to progress through
15 September, so it would be undesirable for any WG Last-Call on PKINIT to close
before that point. Following resolution on the identified patent issue, Brian proposes to
submit a revised PKINIT draft, adding mandatory Diffie-Hellman support, with the result
to be targeted for a working group Last-Call.

PKCROSS is dependent on PKINIT, so cannot advance before it. The most recent
PKCROSS revision added clarifying text about ASN.1 parsers and ticket extensions.


Jack Kabat (Sun) led discussion on a recently submitted draft for GSS-API Java bindings.
Its objectives include satisfying functionality defined in RFC-2078 and 2078bis,
providing Java orientation, and allowing easier usage within a Java environment. Defined
classes include GSSCredential, GSSContext (encapsulates context management), GSSName
(encapsulates name representations), Oid, GSSManager (general class, no constructors),
GSSException, and other utility classes. Initiator-side and acceptor-side code examples
were shown.

Jack noted the following areas in which the Java draft deviates from RFC-2078: error
handling is accommodated via GSSExceptions; memory management relies on garbage
collection; calling conventions differ; java.io stream classes are supported. In defining
Java bindings for GSS, he encountered the following challenges: adapting functional API
into an object-oriented model, hiding complexity, and integration with existing Java
security classes (observation: most Java classes assume certificate-based). Ted Ts'o
(MIT) commented that it would be interesting to explore RMI integration. Sam Hartman
(FundsXpress) observed that it would be nice to have a shim between a C GSS
implementation and exporting the Java API, but was concerned about possible conflicts
with OID representations. Bob Morgan (Stanford) stated that the Open Group is working
on a Kerberos V5 implementation in Java, which might merit investigation. About 18
attendees indicated interest in progressing this draft within the CAT WG, if this can be
accommodated within the WG charter. Further review and comment on the draft was


Tatyana Ryutov (ISI) led discussion on two documents related to authorization services
and interfaces. The work was motivated by the following goals: a need for fine-grained
AC to resources, integrating local and distributed models, user and domain-level policies,
support for various authorization models and authentication policies, and of facilitating
authorization decisions. In the proposed approach, local policies are expressed via
ACLs, and distributed policies via credentials. Optional conditions fields can be added
to both ACLs and credentials.

Once obtained, credentials (which may be based on GSS or other forms of authentication)
are placed into a GAA security context. The Check_authorization call returns one of
"authorized", "not authorized", or "more info needed". Several principal types are defined:
user, group, host, application, and anybody. A GAA context is composed of credentials
and per-connection information reflecting attributes of the would-be accessor. Several
generic conditions are proposed, some of which occur only in credentials rather than ACLs;
review and comment was particularly solicited on the condition constructs. ISI has
implemented a GAA prototype based on Kerberos. A discussion list was announced
specifically for these documents: g3api@isi.edu; further information is available on url
http://gost.isi.edu/info/gaa_api.html. Proposed areas for future work include refinements
to the evaluation facility.

Group discussion on GAA followed. Marc Horowitz didn't see that GAA can support a
distributed authorization server model, where ACLs don't reside at the application. Cliff
Neuman responded that some models of this nature could be supported, invisibly to the
caller; alternatively, a client could request a particular set of operations and corresponding
credentials could be forwarded. Cliff indicated a belief that, in any case, standardizing
ACL formats would be valuable. John Wray (Iris) asked whether and how container
ACLs could be supported. Another question: Has work been done to layer over existing
ACLs (e.g., POSIX, NT), as this would affect the practical value of GAA? Mary Ellen
Zurko (Iris) asked whether multi-personal control was supported; Cliff responded that
this support was possible.

About 8 attendees endorsed progressing GAA within the CAT group, if this can be
accommodated within the WG charter; discussion was encouraged on the WG mailing
list. Cliff observed that there was a significant relationship between GSS and GAA
security contexts. Several attendees commented that a number of other WGs and BOFs
were considering ACLs and authorization, including (as examples) webdav, LDAP
extensions, and a trust management BOF taking place later in the meeting week.


Richard Ward (Microsoft) noted that Kerberos tickets are becoming increasingly larger
as more elements are carried, and larger, and that some protocols have fixed limits. He
posed the prospect that token reassembly might be considered below the GSS interface.
Ted Ts'o and John Wray opposed this suggestion, given compatibility and protocol
layering concerns. Cliff Neuman noted that GAA has upcall functions to obtain
information incrementally as needed, but this was recognized as a separate and longer
term consideration.

Bob Morgan observed that the SASL framework is being incorporated in a number of
protocols, and that SASL allows GSS. Ambiguities had been observed about what
service principal names are to be used; the SASL recommendation is that names of the
host-based service form be used. John Linn recalled discussion with Chris Newman
some months prior, which had led to tightened specification of host-based service name
usage in rfc2078bis. Ted Ts'o observed that this handles some cases, but not those
which are truly application-specific.


None received.

Attendees List

go to list