Common Authentication Technology (cat)
This Working Group Did Not Meet
NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 10-Mar-00
Chair(s):
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:
Done |
|
Preliminary BOF session at IETF meeting, discussions with TELNET and Network Printing Working Groups. |
Done |
|
Distribute Generic Security Service Application Program Interface (GSS-API) documentation through Internet-Draft process. |
Done |
|
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. |
Done |
|
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. |
Done |
|
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. |
Done |
|
Submit service interface specification to to the IESG for consideration as a Proposed Standard. |
Done |
|
Submit GSS-V2 to IESG for consideration as a Proposed Standard. |
Done |
|
Plan next phase of activities, with particular attention to scope and tasking for authorization, store and forward protection support, and additional mechanisms. |
Done |
|
Submit Negotiated Mechanism document to IESG for consideration as a Proposed Standard |
Done |
|
Issue Internet-Draft representing updated version of RFC-2078, aligned with GSS-V2 C bindings Internet-Draft. |
Done |
|
Submit GSS-V2 C bindings document to IESG for consideration as a Proposed Standard. |
Done |
|
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. |
Internet-Drafts:
· Access Control Framework for Distributed Applications
· Generic Authorization and Access control Application Program Interface C-bindings
Request For Comments:
RFC |
Status |
Title |
RFC1510 |
PS |
The Kerberos Network Authentication Service (V5) |
RFC1507 |
E |
DASS - Distributed Authentication Security Service |
RFC1511 |
Common Authentication Technology Overview | |
RFC1964 |
PS |
The Kerberos Version 5 GSS-API Mechanism |
RFC2025 |
PS |
The Simple Public-Key GSS-API Mechanism (SPKM) |
RFC2228 |
PS |
FTP Security Extensions |
RFC2478 |
PS |
The Simple and Protected GSS-API Negotiation Mechanism |
RFC2479 |
Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API) | |
RFC2743 |
PS |
Generic Security Service Application Program Interface Version 2, Update 1 |
RFC2744 |
PS |
Generic Security Service API Version 2 : C-bindings |
RFC2773 |
E |
Encryption using KEA and SKIPJACK |
RFC2847 |
PS |
LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM |
RFC2853 |
PS |
Generic Security Service API Version 2 : Java bindings |