Skip to main content

The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism
RFC 4752

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc: Internet Architecture Board <>,
    RFC Editor <>, 
    sasl mailing list <>, 
    sasl chair <>
Subject: Protocol Action: 'The Kerberos V5 ("GSSAPI") SASL 
         mechanism' to Proposed Standard 

The IESG has approved the following document:

- 'The Kerberos V5 ("GSSAPI") SASL mechanism '
   <draft-ietf-sasl-gssapi-09.txt> as a Proposed Standard

This document is the product of the Simple Authentication and Security 
Layer Working Group. 

The IESG contact persons are Sam Hartman and Tim Polk.

A URL of this Internet-Draft is:

Ballot Text

Technical Summary

   This document provides a revised technical specification for the the
   Simple Authentication and Security Layer (SASL) "GSSAPI" mechanism.
   It uses the Generic Security Service Application Program Interface
   (GSS-API) Kerberos V5 mechanism for authentication and data security
   services.  The previous version of that specification supported both
   the Kerberos V5 mechanism and other mechanisms.  It turns out that
   mechanism provided no way for clients and servers to know they
   supported a common security mechanism before negotiation started.  In
   practice, only the Kerberos V5 mechanism was used.  This specification
   then only specifies the Kerberos V5 mechanism and another working
   group document will correctly specify the use of other GSS-API

   This document replaces section 7.2 of RFC 2222, the previous
   "GSSAPI" technical specification.  This document, together with RFC
4422 obselets RFC 2222. 

Working Group Summary

   This document is a work item of the SASL working group.  The working
   group came to consensus on this document.  There were comments
   received during WG Last Call, and these have been addressed in this

Protocol Quality

   The document was reviewed for the IESG by Sam Hartman.  There were a
   significant number of comments regarding a new requirement that
   clients request integrity protection when negotiating the GSS context.
   A mutually agreeable compromise was reached and updates to the
   Kerberos V5 GSS-API mechanism and base GSS specification were
   suggested.  These updates are out of scope for this document but will
   be considered in appropriate working groups.
RFC-Editor Note

In the header, note that this obseletes RFC 2222.

In section 3, last paragraph:

  Note that if during a SASL authentication exchange any GSS-API call
  returns major_status other than GSS_S_COMPLETE (or
  GSS_S_CONTINUE_NEEDED for GSS_Init_sec_context/
  GSS_Accept_sec_context) then the SASL authentication exchange MUST be
  considered unsuccessful.

  Note that major status codes returned by GSS_Init_sec_context() or
  GSS_Accept_sec_context() other than GSS_S_COMPLETE or
  GSS_S_CONTINUE_NEEDED cause authentication failure.  Major status
  codes returned by GSS_Unwrap() other than GSS_S_COMPLETE (without any
  additional supplementary status codes) cause authentication and/or
  security layer failure.


   The registry is at

RFC Editor Note