Re: GSS-API
John Linn <linn@gza.com> Tue, 17 August 1993 12:27 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01926; 17 Aug 93 8:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01918; 17 Aug 93 8:27 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa05208; 17 Aug 93 8:27 EDT
Received: by bitsy.MIT.EDU id AA17425; Tue, 17 Aug 93 08:16:45 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP id AA17419; Tue, 17 Aug 93 08:16:44 EDT
Received: from pad-thai.aktis.com by MIT.EDU with SMTP id AA22606; Tue, 17 Aug 93 08:16:39 EDT
Received: from gza-server.aktis.com by pad-thai.aktis.com (8.5/) with SMTP id <IAA07188@pad-thai.aktis.com>; Tue, 17 Aug 1993 08:17:03 -0400
Received: by gza-server.aktis.com (4.1/4.7) id AA16671; Tue, 17 Aug 93 08:17:02 EDT
Message-Id: <9308171217.AA16671@gza-server.aktis.com>
To: leach@zergo.com
Cc: linn@gza.com, cat-ietf@mit.edu
Subject: Re: GSS-API
In-Reply-To: Your message of "Mon, 16 Aug 1993 16:51:57 -0000." <115@zergo.com>
Date: Tue, 17 Aug 1993 08:17:01 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: John Linn <linn@gza.com>
John, GSS-API and I are both still alive and well. As the attached message from June indicates, the current versions of the Internet-Drafts (more recent than the version you were looking at) have been approved for RFC publication and should appear as numbered RFCs shortly, following processing by the RFC editor. --jl Received: from BITSY.MIT.EDU by pad-thai.aktis.com (5.67/) with SMTP id <AA28889@pad-thai.aktis.com>; Tue, 29 Jun 93 08:22:37 -0400 Received: by bitsy.MIT.EDU id AA09732; Tue, 29 Jun 93 08:14:58 EDT Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP id AA09726; Tue, 29 Jun 93 08:14:56 EDT Received: from ietf.cnri.reston.va.us by MIT.EDU with SMTP id AA12346; Tue, 29 Jun 93 08:14:47 EDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa01634; 29 Jun 93 8:13 EDT To: IETF-Announce:;@CNRI.Reston.VA.US Cc: Jon Postel -- RFC Editor <postel@isi.edu> Cc: Internet Architecture Board <iab@isi.edu> Cc: cat-ietf@MIT.EDU Cc: The Internet Engineering Steering Group <IESG@IETF.CNRI.Reston.VA.US> From: IESG Secretary <iesg-secretary@CNRI.Reston.VA.US> Subject: Protocol Action: Common Authentication Technology Protocols to Proposed Standard Date: Tue, 29 Jun 93 08:13:35 -0400 Sender: jstewart@CNRI.Reston.VA.US Message-Id: <9306290813.aa01634@IETF.CNRI.Reston.VA.US> The IESG has approved the Internet-Drafts: o "Generic Security Service Application Program Interface" <draft-ietf-cat-genericsec-04.txt> o "The Kerberos Network Authentication Service (V5)" <draft-ietf-cat-kerberos-02.txt, .ps> o "Generic Security Service API : C-bindings" <draft-ietf-cat-secservice-02.txt> as a Proposed Standard. This document is the product of the Common Authentication Technology Working Group. The IESG contact person is Stephen Crocker. Technical Summary The top-level GSS-API document has been reviewed by three independent individuals, all of whom provided comments that have been accommodated by the document's editor. The GSS-API C bindings and Kerberos V5 specifications have also been independently reviewed. Each of the documents has been the basis for implementation activities. The publication of these specifications as Internet standards should foster widespread deployment of authentication and integrity services in connection-oriented protocols, e.g., TELNET and FTP. By insulating protocols from the details of the security services, the CAT approach frees them to focus on completing their task and assures that all protocols benefit from the availability of robust and stable security services,i.e., each protocol need not revisit the issues. Technical Summary of <draft-ietf-cat-genericsec-04.txt> This Generic Security Service Application Program Interface (GSS-API) definition provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. This specification defines GSS-API services and primitives at a level independent of underlying mechanism and programming language environment, and is to be complemented by other, related specifications: o documents defining specific parameter bindings for particular language environments o documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms The operational paradigm in which GSS-API operates is as follows. A typical GSS-API caller is itself a communications protocol, calling on GSS-API in order to protect its communications with authentication, integrity, and/or confidentiality security services. A GSS-API caller accepts tokens provided to it by its local GSS-API implementation and transfers the tokens to a peer on a remote system; that peer passes the received tokens to its local GSS-API implementation for processing. The security services available through GSS-API in this fashion are implementable (and have been implemented) over a range of underlying mechanisms based on secret-key and public-key cryptographic technologies. The GSS-API separates the operations of initializing a security context between peers, achieving peer entity authentication, from the operations of providing per-message data origin authentication and data integrity protection for messages subsequently transferred in conjunction with that context. Per-message calls provide the data origin authentication and data integrity services and also support selection of confidentiality services as a caller option. Additional calls provide supportive functions to the GSS-API's users. The GSS-API design assumes and addresses several basic goals, including: o Mechanism independence: The GSS-API defines an interface to cryptographically implement strong authentication and other security services at a generic level which is independent of particular underlying mechanisms. For example, GSS-API-provided services can be implemented by secret-key technologies (e.g., Kerberos) or public-key approaches (e.g., X.509). o Protocol environment independence: The GSS-API is independent of the communications protocol suites with which it is employed, permitting use in a broad range of protocol environments. In appropriate environments, an intermediate implementation "veneer" which is oriented to a particular communication protocol (e.g., Remote Procedure Call (RPC)) may be interposed between applications which call that protocol and the GSS-API, thereby invoking GSS-API facilities in conjunction with that protocol's communications invocations. o Protocol association independence: The GSS-API's security context construct is independent of communications protocol association constructs. This characteristic allows a single GSS-API implementation to be utilized by a variety of invoking protocol modules on behalf of those modules' calling applications. GSS-API services can also be invoked directly by applications, wholly independent of protocol associations. o Suitability to a range of implementation placements: GSS- API clients are not constrained to reside within any Trusted Computing Base (TCB) perimeter defined on a system where the GSS-API is implemented; security services are specified in a manner suitable to both intra-TCB and extra-TCB callers. Technical Summary of <draft-ietf-cat-secservice-02.txt> This draft document specifies C language bindings for the Generic Security Service Application Program Interface (GSS-API), which is described at a language-independent conceptual level in the preceding draft. It has been the basis for multiple prototyping and implementation activities, and has been refined as a result of the experience gained. Technical Summary of <draft-ietf-cat-kerberos-02.<txt,ps>> This document gives an overview and specification of Version 5 of the protocol for the Kerberos network authentication system. Version 4, described elsewhere, is presently in production use at MIT's Project Athena, and at other Internet sites. Working Group Summary The CAT Working Group was chartered to create the GSS-API specifications and specifications for supporting mechanisms; the current set of documents represent substantial work, working group consensus, and have been available as Internet-Drafts since 1992. It is recognized, and was recognized when the WG was chartered, that API definition is an unusual activity for (traditionally protocol-oriented) IETF WGs; the fact that this API is targeted for consumption by IETF-standardized protocols as a means for integrating security into those protocols provides rationale for carrying out this work in the IETF environment. The current Kerberos V5 specification as proposed for advancement represents the culmination of many years' implementation and specification effort. It is expected that additional CAT mechanisms will be documented in Internet standards-track and experimental specifications. Protocol Quality The documents are well-written and easy to understand. It is the belief of the WG that this set of specifications will be sufficient to support independent implementations, and indeed the set has served as the basis for several prototype and development activities. While no implementations available at this time are wholly complete and updated to match the current document versions, it is anticipated that advancement of the specifications to Proposed Standards will engender broadened and intensified development efforts. --jl
- GSS-API John Leach
- GSS-API Scherer Annette
- Re: GSS-API John Linn