Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family
RFC 5801

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    sasl mailing list <sasl@ietf.org>, 
    sasl chair <sasl-chairs@tools.ietf.org>
Subject: Protocol Action: 'Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family' to Proposed Standard

The IESG has approved the following document:

- 'Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family '
   <draft-ietf-sasl-gs2-20.txt> as a Proposed Standard


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

The IESG contact persons are Pasi Eronen and Tim Polk.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-gs2-20.txt

Ballot Text

Technical Summary 

   This document describes how to use a Generic Security Service
   Application Program Interface (GSS-API) mechanism in the the Simple
   Authentication and Security Layer (SASL) framework. This is done by
   defining a new SASL mechanism family, called GS2. This mechanism
   family offers a number of improvements over the previous "SASL/
   GSSAPI" mechanism: it is more general, uses fewer messages for the
   authentication phase in some cases, and supports negotiable use of
   channel binding. Only GSS-API mechanisms that support channel
   binding are supported.

Working Group Summary

   The document went through several redesign phases, which resulted
   in drastic change in on the wire representation.  However it
   represents strong WG consensus.

   There were significant and long discussions over channel binding
   type negotiation.  After long considerations, it was decided to
   leave channel binding type negotiation external to GS2 and to
   provide a default of tls-unique. This simplify the design and makes
   it easy to implement in popular configurations (i.e., together with
   TLS). I believe that today this has strong support in the WG.

   There was also a recent discussion about IANA registration
   procedure for SASL mechanisms starting with GS2- prefix. The
   discussion resulted in consensus that the document is correct as
   written.

Document Quality

   At least a couple (both clients and server) implementations of the
   document are planned.

Personnel

   Alexey Melnikov is the document shepherd for this document,
   and Pasi Eronen is the responsible area director.

RFC Editor Note