Subject: Re: [kitten] RFC2743 errata 4251

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 25 Feb 2015 11:40:12 -0500 (EST)

On Tue, 20 Jan 2015, Benjamin Kaduk wrote:

> On Tue, 20 Jan 2015, Benjamin Kaduk wrote:
>
> >      In practice, an unexpected security context token that imediately
> >      follows full security context establishment is very likely a
> >      context token conveying error information rather than a security
> >      context deletion token, especially since the latter are obsoleted.
>
> Given what Jeff pointed out about new statements in errata being taken as
> indicating important (new) changes, I wonder if this paragraph should also
> be removed.  I believe it to be a true statement, but perhaps including it
> in the erratum at all will give it more weight than is appropriate.  It is
> also the first mention of deletion tokens in section 2.2.4 (another
> mention does occur later on), so it comes in somewhat abruptly without
> introduction.
>
> >      Applications using transports that may deliver messages out of
> >      order may continue to attempt to process per-message tokens between
> >      calling GSS_Process_context_token() and GSS_Delete_sec_context(),
> >      though there is no guarantee that processing per-message tokens will
> >      then succeed.
>
> This also may be too much information for the erratum.  (Again, I believe
> it is basically a correct statement, but that including it in the erratum
> may cause it to be given too much weight.)
>
> What do other people think?

This doesn't seem to have received any replies, so let me rephrase in the
form of a new proposed erratum text:

======================================================

  Section 2.2.4 says:

     o  GSS_S_FAILURE indicates that the context is recognized, but that
     the GSS_Process_context_token() operation could not be performed
     for reasons unspecified at the GSS-API level.

  It should say:

     o  GSS_S_FAILURE indicates that the context is recognized, but
     either the GSS_Process_context_token() operation could not be
     performed for reasons unspecified at the GSS-API level, or the peer
     had an error consuming the last context token sent to it.  The latter
     occurs when the local side became fully established and produced one
     last token which was sent to the peer, but the peer encountered an
     error while processing that last context token.  In either case the
     minor status code provides additional information.

     In the case of successful processing of error tokens, the minor
     status code provides information from the input token.  The display
     string outputs of GSS_Display_status() as applied to such minor
     status codes should indicate that the error originated on the remote
     peer, along with the nature of the error.  Note that there is no
     way to distinguish failures of GSS_Process_context_token() from
     error token information other than to read the human-readable status
     display strings.

======================================================

Removing the last paragraph ("Applications using transports ...") removes
the only text implying that callers of GSS_Process_context_token() are
still required to eventually call GSS_Delete_sec_context().  Do we think
that text to that effect is needed in this erratum (as opposed to a
separate one)?

-Ben

---

From: Nico Williams <[email-masked]>
Date: Wed, 25 Feb 2015 11:15:12 -0600

I believe this text is correct.

As to Ben's question, I don't think text to the effect of when the
application should get around to calling GSS_Delete_sec_context() is
needed.  Application developers will end up figuring that out for
themselves.

Nico
--

---

From: Greg Hudson <[email-masked]>
Date: Wed, 25 Feb 2015 16:36:46 -0500

>      error token information other than to read the human-readable status

This seems okay to me.