The Simple and Protected GSS-API Negotiation Mechanism
RFC 2478

Document Type RFC - Proposed Standard (December 1998; No errata)
Obsoleted by RFC 4178
Authors Eric Baize  , Denis Pinkas 
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 2478 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         E. Baize
Request for Comments: 2478                                   D. Pinkas
Category: Standards Track                                         Bull
                                                         December 1998

         The Simple and Protected GSS-API Negotiation Mechanism

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.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.


   This document specifies a Security Negotiation Mechanism for the
   Generic Security Service Application Program Interface (GSS-API)
   which is described in [1].

   The GSS-API provides a generic interface which can be layered atop
   different security mechanisms such that if communicating peers
   acquire GSS-API credentials for the same security mechanism, then a
   security context may be established between them (subject to policy).
   However, GSS-API doesn't prescribe the method by which GSS-API peers
   can establish whether they have a common security mechanism.

   The Simple and Protected GSS-API Negotiation Mechanism defined here
   is a pseudo-security mechanism, represented by the object identifier ( which
   enables GSS-API peers to determine in-band whether their credentials
   share common GSS-API security mechanism(s), and if so, to invoke
   normal security context establishment for a selected common security
   mechanism. This is most useful for applications that are based on
   GSS-API implementations which support multiple security mechanisms.

   This allows to negotiate different security mechanisms, different
   options within a given security mechanism or different options from
   several security mechanisms.

Baize & Pinkas              Standards Track                     [Page 1]
RFC 2478             GSS-API Negotiation Mechanism         December 1998

   Once the common security mechanism is identified, the security
   mechanism may also negotiate mechanism-specific options during its
   context establishment. This will be inside the mechanism tokens, and
   invisible to the SPNEGO protocol.

   The simple and protected GSS-API mechanism negotiation is based on
   the following negotiation model : the initiator proposes one security
   mechanism or an ordered list of security mechanisms, the target
   either accepts the proposed security mechanism, or chooses one from
   an offered set, or rejects the proposed value(s). The target then
   informs the initiator of its choice.

   In its basic form this protocol requires an extra-round trip. Network
   connection setup is a critical performance characteristic of any
   network infrastructure and extra round trips over WAN links, packet
   radio networks, etc. really make a difference. In order to avoid such
   an extra round trip the initial security token of the preferred
   mechanism for the initiator may be embedded in the initial token. If
   the target preferred mechanism matches the initiator's preferred
   mechanism, no additional round trips are incurred by using the
   negotiation protocol.

   The simple and protected GSS-API mechanism negotiation provides a
   technique to protect the negotiation that must be used when the
   underlying mechanism selected by the target is capable of integrity

   When all the mechanisms proposed by the initiator support integrity
   protection or when the selected mechanism supports integrity
   protection, then the negotiation mechanism becomes protected since
   this guarantees that the appropriate mechanism supported by both
   peers has been selected.

   The Simple and Protected GSS-API Negotiation Mechanism uses the
   concepts developed in the GSS-API specification [1]. The negotiation
   data is encapsulated in context-level tokens. Therefore, callers of
   the GSS-API do not need to be aware of the existence of the
   negotiation tokens but only of the new pseudo-security mechanism. A
   failure in the negotiation phase causes a major status code to be
   returned: GSS_S_BAD_MECH.

Baize & Pinkas              Standards Track                     [Page 2]
RFC 2478             GSS-API Negotiation Mechanism         December 1998


2.1.  Negotiation description

   The model for security mechanism negotiation reuses a subset of the
   concepts specified in [2].

   Each OID represents one GSS-API mechanism or one variant of it.

    -  When one security mechanism is proposed by the initiator, it
       represents the only security mechanism supported or selected
Show full document text