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

Document Type RFC - Proposed Standard (October 1996; No errata)
Author Carlisle Adams 
Last updated 2013-03-02
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2025 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           C. Adams
Request for Comments: 2025                        Bell-Northern Research
Category: Standards Track                                   October 1996

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

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.


   This specification defines protocols, procedures, and conventions to
   be employed by peers implementing the Generic Security Service
   Application Program Interface (as specified in RFCs 1508 and 1509)
   when using the Simple Public-Key Mechanism.


   Although the Kerberos Version 5 GSS-API mechanism [KRB5] is becoming
   well-established in many environments, it is important in some
   applications to have a GSS-API mechanism which is based on a public-
   key, rather than a symmetric-key, infrastructure.  The mechanism
   described in this document has been proposed to meet this need and to
   provide the following features.

     1)  The SPKM allows both unilateral and mutual authentication
         to be accomplished without the use of secure timestamps.  This
         enables environments which do not have access to secure time
         to nevertheless have access to secure authentication.

     2)  The SPKM uses Algorithm Identifiers to specify various
         algorithms to be used by the communicating peers.  This allows
         maximum flexibility for a variety of environments, for future
         enhancements, and for alternative algorithms.

     3)  The SPKM allows the option of a true, asymmetric algorithm-
         based, digital signature in the gss_sign() and gss_seal()
         operations (now called gss_getMIC() and gss_wrap() in
         [GSSv2]), rather than an integrity checksum based on a MAC
         computed with a symmetric algorithm (e.g., DES).  For some
         environments, the availability of true digital signatures
         supporting non-repudiation is a necessity.

Adams                       Standards Track                     [Page 1]
RFC 2025                          SPKM                      October 1996

     4)  SPKM data formats and procedures are designed to be as similar
         to those of the Kerberos mechanism as is practical.  This is
         done for ease of implementation in those environments where
         Kerberos has already been implemented.

   For the above reasons, it is felt that the SPKM will offer
   flexibility and functionality, without undue complexity or overhead.

Key Management

   The key management employed in SPKM is intended to be as compatible
   as possible with both X.509 [X.509] and PEM [RFC-1422], since these
   represent large communities of interest and show relative maturity in


   Much of the material in this document is based on the Kerberos
   Version 5 GSS-API mechanism [KRB5], and is intended to be as
   compatible with it as possible.  This document also owes a great debt
   to Warwick Ford and Paul Van Oorschot of Bell-Northern Research for
   many fruitful discussions, to Kelvin Desplanque for implementation-
   related clarifications, to John Linn of OpenVision Technologies for
   helpful comments, and to Bancroft Scott of OSS for ASN.1 assistance.

1. Overview

   The goal of the Generic Security Service Application Program
   Interface (GSS-API) is stated in the abstract of [RFC-1508] as

     "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:

       - documents defining specific parameter bindings for particular
         language environments;

       - documents defining token formats, protocols, and procedures to
         be implemented in order to realize GSS-API services atop
         particular security mechanisms."

Adams                       Standards Track                     [Page 2]
RFC 2025                          SPKM                      October 1996

   The SPKM is an instance of the latter type of document and is
   therefore termed a "GSS-API Mechanism".  This mechanism provides
   authentication, key establishment, data integrity, and data
   confidentiality in an on-line distributed application environment
Show full document text