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.
Personnel
Matthew Miller (kitten WG co-chair) is the document shepherd and
Stephen Farrell is the responsible Area Director.