Document Action: 'Structure of the GSS Negotiation Loop' to Informational RFC (draft-ietf-kitten-gss-loop-05.txt)

The IESG <> Tue, 24 February 2015 14:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C517E1A1BB3; Tue, 24 Feb 2015 06:43:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j_Z5ExxKcrDE; Tue, 24 Feb 2015 06:43:09 -0800 (PST)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id A7AC21A1BD9; Tue, 24 Feb 2015 06:43:07 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <>
To: IETF-Announce <>
Subject: Document Action: 'Structure of the GSS Negotiation Loop' to Informational RFC (draft-ietf-kitten-gss-loop-05.txt)
X-Test-IDTracker: no
X-IETF-IDTracker: 5.11.0.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <>
Date: Tue, 24 Feb 2015 06:43:07 -0800
Archived-At: <>
Cc: kitten mailing list <>, kitten chair <>, RFC Editor <>
X-Mailman-Version: 2.1.15
List-Id: "IETF announcement list. No discussions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Feb 2015 14:43:10 -0000

The IESG has approved the following document:
- 'Structure of the GSS Negotiation Loop'
  (draft-ietf-kitten-gss-loop-05.txt) as Informational RFC

This document is the product of the Common Authentication Technology Next
Generation Working Group.

The IESG contact persons are Stephen Farrell and Kathleen Moriarty.

A URL of this Internet Draft is:

Technical Summary

  This document provides guidance for implementing the GSS
  negotiation loop.  It describes expectations of application
  protocols that use GSSAPI, such as error reporting and separation
  of application data from security negotiation data; the expected
  inputs and outputs for GSS_Accept_sec_context() and 
  GSS_Init_sec_context(), including how various status codes should
  be handled; and what applications are expected to do once the loop
  completes.  This document also describes what applications should
  do with unexpected state conditions.

Working Group Summary

  This document went through two separate Working Group Last Calls
  with extensive discussion from a number of participants.

  One concern discussed is if this document should normatively update
  RFC 2743 or if it should "merely" provide application developers
  guidnace for how to work with GSSAPI as it exists today.
  The consensus ultimately was for this document to provide guidance
  for the current state of the art.

  Another major concern was the behavior when a context token is
  received after the security context is established.  The consensus
  was for implementers to always call GSS_Process_context_token(),
  then call GSS_Inquire_context() to determine the usability of the
  security context, and call GSS_Delete_sec_context() to clean up.
  This document acknowledges that the current state of GSSAPI
  implementations renders the security context unusable when such
  context tokens are processed.

  In the course of discussing and updating this document, erratum
  4151 was filed against RFC 2743 regarding the output of
  GSS_Process_context_token().  The erratum has not yet been
  formally discussed or verified in the Working Group.

Document Quality

  This is informational and seems good to the AD.

   I-D nits asked about the code fragment but the authors/chairs
   discussed that and prefer to note add begin/end as the code
   is one fragment in it's own sub-section with a comment to the
   same effect.


   Matthew Miller (kitten WG co-chair) is the document shepherd and
   Stephen Farrell is the responsible Area Director.