Subject: Re: [kitten] RFC2743 errata 4251

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 14 Jan 2015 16:12:50 -0500

On Fri, 2014-12-19 at 18:16 -0600, Nico Williams wrote:
> On further thought, since context deletion tokens are obsoleted, and
> have been for a long time, we might as well say nothing about
> GSS_S_COMPLETE implying that the peer is done using its side of the
> security context.  The GSS_S_FAILURE case, however, still kinda leads to
> the caller being done.
> 
> OLD PROPOSED TEXT
> |      Though future GSS-API extensions may add new uses of asynchronous
> |      security context tokens and ways to process them, applications
> |      using the GSS-API version 2, update 1, should generally call
> |      GSS_Delete_sec_context() after calling GSS_Process_context_token(),
> |      when the latter returns GSS_S_COMPLETE or GSS_S_FAILURE.
> 
> NEW:
> |      Applications should generally call GSS_Delete_sec_context() when
> |      GSS_Process_context_token() returns GSS_S_FAILURE.

FWIW, I agree with Greg that it's not reasonable to assume, or suggest
that applications assume, that all asynchronous context tokens are
deletion tokens or mean that the context is now dead.  So, the above
change is an improvement.

However, after reading this thread, I'm not convinced we need to give
applications any guidance about calling GSS_Delete_sec_context after
processing a context token.  Nico thinks that saying "generally" makes
it OK, but I disagree.  The word "generally" here isn't an effective
weasel word; it's a particle.  If you describe what the exceptions are,
you don't need it, and if you don't, then it doesn't do you any good.
Implementors are going to read the text as if the word wasn't there.

I think it is worth noting that if we start giving new implementation
guidance to applications in an erratum, people who read it will assume
it must be important and start doing that, because otherwise, why did we
go out of our way to publish an erratum?

The purpose of errata is to fix technical or editorial errors and
omissions in the existing spec.  They are not for changing the spec or
offering new guidance.  We should stick to doing the former, and leave
the latter for a new or updated document, if it's necessary.

-- Jeff

---

From: Nico Williams <[email-masked]>
Date: Wed, 14 Jan 2015 15:48:32 -0600

Fair enough.  Thanks for reviewing this Jeff.

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 20 Jan 2015 16:25:32 -0500 (EST)

> go out of our way to publish an erratum?

Thank you for the input, Jeff.  I think this point has not really been
mentioned yet in our discussions, and is an important one.

> the latter for a new or updated document, if it's necessary.

I think this makes the current proposal under consideration (removing
entirely the paragraph which attempted to give applications guidance on
when to call GSS_Delete_sec_context()):

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

  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.

     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.

     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.

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

I will send my thoughts in a separate message.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 20 Jan 2015 20:20:36 -0500 (EST)

> when to call GSS_Delete_sec_context()):

"had an error" feels slightly informal; I might prefer "experienced an
error" or something like that.

>      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.

>      though there is no guarantee that processing per-message tokens will

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?

-Ben

> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>