1. Summary
Matthew Miller (kitten WG co-chair) is the document shepherd and
Stephen Farrell is the responsible Area Director.
This document provides guidance for implementing the GSS
negotation loop. It describes expectations of application
protocols that use GSSAPI, such as error reporting and separation
of application data from security negotation 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.
2. Review and Consensus
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.
3. Intellectual Property
This document only describes guidance for implementing other
standards track documents, and does not define any new art.
Still, the author has confirmed conformance with BCPs 78 and 79,
and there are no IPR declrations against this document.
4. Other Points
There are no normative downrefs.
There are no IANA considerations.
A nit is reported about a "code comment" not surrounded by a
delimiter. The "code comment" is the sole content of section 5.1,
and the leading text makes it clear that is the case. Ignoring the
nit should be safe.