Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: Internet Architecture Board <email@example.com>, RFC Editor <firstname.lastname@example.org>, sasl mailing list <email@example.com>, sasl chair <firstname.lastname@example.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
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.