Re: [kitten] RFC2743 errata 4251

[Greg Hudson <[e-mail]>]

On 12/15/2014 12:50 PM, Nico Williams wrote:
>> (To be clear: saying that applications must eventually call
>> GSS_Delete_sec_context() is fine; saying that they should do so
>> immediately after a GSS_S_COMPLETE from GSS_Process_context_token() is
>> not fine.)
[...]
> Therefore the caller of GSS_Process_context_token(), while they can
> continue to process per-msg tokens from the peer, has to get around to
> calling GSS_Delete_sec_context().

I think I acknowledged above that it must do so eventually (that is, it
must not assume that calling GSS_Process_context token discharged its
responsibility to release the context, despite the lack of a
GSS_Delete_sec_context call by the client in the RFC 2743 section 1
narrative).

> In v2u1, the peer has indicated that it can't continue, so
> calling GSS_Wrap() and GSS_GetMIC() does the app no good[**].

I don't think that is really specified in RFC 2743.  Section 2.2.4 says
"one use..." and then "another use..." but doesn't say that's a
comprehensive list of context token types.  If the authors had intended
for these two uses to be a comprehensive list, I would have expected
more specific language than "impact on context-level state information"
in the preceding sentence.

> Thus also the very specific reference to a GSS-API version (v2u1): it's
> quite true that a GSS-APIv2u1 application could not properly handle a v3
> extension that uses async context tokens.  What could a v2u1 application
> possibly do to properly handle such an extension?  How could it interpret
> the major/minor status codes (other than GSS_S_DEFECTIVE_TOKEN) from
> GSS_Process_context_token() to determine whether the app should
> continue?  If it can't, then how could it decide whether to keep going
> instead of getting around to calling GSS_Delete_sec_context()?

It can try to keep going, and terminate the context when it runs into an
error or a transport-level or application-level closure.  I think this
is the right behavior to encourage given the text in RFC 2743.

> A GSS-APIv2u1 app just has to end up calling GSS_Delete_sec_context()
> when GSS_Process_context_token() returns either GSS_S_COMPLETE or
> GSS_S_FAILURE -- and "soon" after, too.

I don't see a compelling reason to encourage doing so "soon" after a
GSS_S_COMPLETE.