The Simple Public-Key GSS-API Mechanism (SPKM) (RFC2025)
Original Publication Date: 1996-Oct-01
Included in the Prior Art Database: 2000-Sep-13
Internet Society Requests For Comment (RFCs)
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.
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.
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.