Subject: Re: [kitten] RFC2743 errata 4251

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 9 Dec 2014 16:36:41 -0500 (EST)

Some potential tweaks.

On Mon, 24 Nov 2014, Nico Williams wrote:

> New proposal:
>
>   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 (when the

I might make the parenthentical be a new sentence, and reword it slightly
to:

In order for errors from the peer to be conveyed as input context tokens
to GSS_Process_context_token() (as opposed to one of the
context-establishment calls GSS_Init_sec_context() or
GSS_Accept_sec_context()), the local side must already have been fully
established but the remote peer's side not established.

>      local side must have been fully established but the peer hadn't yet
>      been).  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 this, but note that there is no way to

"this" is vague.  How about "that the error originated on the remote peer,
along with the nature of the error"?

At this point, the sentence is getting a bit long, so breaking before "but
note" and just starting a new sentence with "Note" may be in order.

>      distinguish failures of GSS_Process_context_token() from error
>      token information other than to read the human-readable status
>      display strings.  Since status display strings are not machine-
>      readable, there is no way to programmatically make this
>      distinction.

Again about "this".
Perhaps "programmatically distinguish between an error internal to
GSS_Process_context_token() and a supplied error token"?

>      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.
>
>      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.
>
>      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's no guarantee that processing per-message tokens will

I have a marginal preference for avoiding contractions in formal documents
(i.e., "there is").

>      then succeed.
>
> I hope this addresses all concerns, both Martin's and those arising from
> the loop I-D.
>
> Feel free to propose alternative text.

How do you feel about the tidbits above?

-Ben

---

From: Nico Williams <[email-masked]>
Date: Tue, 9 Dec 2014 15:55:24 -0600

On Tue, Dec 09, 2014 at 04:36:41PM -0500, Benjamin Kaduk wrote:
> I might make the parenthentical be a new sentence,

Maybe.

>                                             [...], and reword it slightly
> to:

This is just the re-write of the parenthetical?

> established but the remote peer's side not established.

How about:
                                                    [...], or the peer
   had an error consuming the last context token sent to it.  [insert here]

                                                              The latter
   occurs when the local side became fully established upon producing
   one last context token that then triggered an error on the remote
   peer.  In either case the minor status code...

> along with the nature of the error"?

Agreed.

> note" and just starting a new sentence with "Note" may be in order.

Agreed.

> >      readable, there is no way to programmatically make this

Well, the following word ('distinction') relates to the previous
sentence's 'distinguish', so I think it's safe.  We could just... remove
that last sentence and be done: it adds nothing[*].

[*] So why did I write it in the first place?

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 9 Dec 2014 19:02:54 -0500 (EST)

> This is just the re-write of the parenthetical?

Correct.  (It's a bit long for such a re-write.)

>    peer.  In either case the minor status code...

That's better than mine, but probably still has some room for tweaking.
Just throwing something out there:

The latter occurs when the local side became fully established and
produced one last context token which was sent to the peer, but the peer
encountered an error while processing that last context token.

> that last sentence and be done: it adds nothing[*].

I think I would be okay with that.

> [*] So why did I write it in the first place?

I don't know :)

Once we nail down the text about why the peer would be producing an error
token, I can turn this into a new erratum candidate text.

-Ben

---

From: Nico Williams <[email-masked]>
Date: Tue, 9 Dec 2014 18:24:45 -0600

> encountered an error while processing that last context token.

Sold.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 10 Dec 2014 13:57:50 -0500 (EST)

> Sold.

Okay, so now we're looking at:

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

  Section 2.2.4 says:

  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.

     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.

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

It would be good to hear comments from people other than Nico and I.
(Martin?  Greg?)

-Ben

---

From: Greg Hudson <[email-masked]>
Date: Mon, 15 Dec 2014 12:20:30 -0500

>      when the latter returns GSS_S_COMPLETE or GSS_S_FAILURE.

I don't like the wording of this part.  Encouraging applications to
assume that context tokens destroy the context essentially closes the
door to specifying context tokens which don't.

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

Otherwise the new text looks good.

---

From: Nico Williams <[email-masked]>
Date: Mon, 15 Dec 2014 11:50:38 -0600

> immediately after a GSS_S_COMPLETE from GSS_Process_context_token() is

GSS-APIv2u1 callers can still call GSS_Unwrap(), GSS_VerifyMIC(), and
GSS_Pseudo_random()[*], and even GSS_Wrap() and GSS_GetMIC() before
calling GSS_Delete_sec_context(), however, as it is today processing an
async context token does mean that the other peer cannot continue.
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().  Sure, exiting, crashing, hanging
around doing nothing -- these are also options, but not really desirable
ones.  In v2u1, the peer has indicated that it can't continue, so
calling GSS_Wrap() and GSS_GetMIC() does the app no good[**].

Thus the word "generally".  It's a bit of a weasel word that captures
all of the above possibilities.

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()?

I don't see how a GSS-APIv2u1 application could make that determination.

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.

[*]  Hmmm, should we consider GSS_Pseudo_random() to be part of a v2u2?

[**] A vwu1 peer could have done GSS_Export_sec_context(), then imported
     it twice and then called GSS_Delete_sec_context() on one of them,
     producing a context deletion token, and sent it, while then
     continuing to use the second imported version.  This would be
     rather tortured behavior!  No app does this.

Nico
--

---

From: Greg Hudson <[email-masked]>
Date: Mon, 15 Dec 2014 13:09:41 -0500

>> immediately after a GSS_S_COMPLETE from GSS_Process_context_token() is
[...]
> 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

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.

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

> GSS_S_FAILURE -- and "soon" after, too.

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

---

From: Nico Williams <[email-masked]>
Date: Mon, 15 Dec 2014 12:25:07 -0600

> GSS_Delete_sec_context call by the client in the RFC 2743 section 1

All apps must do so eventually, async context tokens or not.
"Eventually" could mean "at the end of time".  But here it has a more
specific meaning: the "connection" state must be "cleanup", whatever
that means to the app.

> in the preceding sentence.

By elimination we know that no other outcomes are possible in the v2u1
API.

> is the right behavior to encourage given the text in RFC 2743.

But why bother with async context tokens then?

I do see an argument for continuing: that an error token might have no
integrity protection and the app can't tell, therefore the app should
continue just in case.

(Indeed, KRB-ERRORs today don't have integrity protection.  The krb5
mech could just always return GSS_S_DEFECTIVE_TOKEN when processing
unprotected KRB-ERRORs, with the peer-side error captured in the minor
status.  This could either be required behavior for the mechanism, or
locally configurable.)

But then, neither would a TCP FIN/RST... unless IPsec or some TCPINC
protocol are in use, in which case the possible lack of integrity
protection for a GSS error token is irrelevant.  There's also no
integrity protection for a non-responsive peer.  I.e., active attackers
can DoS a security context.  That's not news though...

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

I don't see a compelling reason not to.  Again, this is tied to a very
specific GSS-API version: v2u1 and all versions until there is an
enhancement to the API that uses async context tokens.

I don't think there ever will be such an extension.  The use case I can
think of, re-keying, doesn't really require async context tokens, and
has fallen out of favor in the TLS community.  There's a whole off-list
discussion that would have to get brought on-list to pursue this angle,
which I'd like to do eventually.

Nico
--

---

From: Greg Hudson <[email-masked]>
Date: Mon, 15 Dec 2014 13:37:47 -0500

> By elimination we know that no other outcomes are possible in the v2u1

I don't follow this argument, and I think this point is pretty fundamental.

> But why bother with async context tokens then?

To communicate better error information to callers?  To support
re-keying or other mechanism-specified context tokens which might
improve security?

> integrity protection and the app can't tell, therefore the app should

This is not my reasoning; my reasoning is simply that the application
has no strong reason to believe that the context has been terminated,
and that encouraging applications to make this assumption unnecessarily
closes the door to other uses.

---

From: Nico Williams <[email-masked]>
Date: Mon, 15 Dec 2014 13:48:08 -0600

> closes the door to other uses.

If the token is a deletion token, then yes, it has such a strong reason.

If it's an error token then... it depends on whether the peer ever was
PROT_READY: if not, then there's no way to continue, else... it could
continue without authentication and other services, but why would an
application do this?  Actually, that's not farfetched.  If the two peers
successfully exchanged ephemeral DH keys but did not authenticate them
then the app could tunnel a new authentication attempt protected by the
unauthenticated one, thus obtaining protection from off-path attackers.

That would be the argument that wins me over (and it's why I'm eliding
my responses to your other points; those might be moot), if anyone cares
to make it (I might!  I'll have to think about it).

Nico
--

---

From: [email-masked] (Martin Rex)
Date: Mon, 15 Dec 2014 22:52:31 +0100 (CET)

>> door to specifying context tokens which don't.

GSS_Process_context_token() will typically mark a security context
as "no longer usable" (but leave the context handle itself intact).
It is a "local matter" (read: implementation defined) whether
a gssapi mechanism destroys cryptographic keying material associated
with the security context handle already within GSS_Process_context_token()
or only upon cleanup when GSS_Delete_sec_context() is called.

> calling GSS_Delete_sec_context(), however,

You mean calling GSS_Unwrap(), GSS_VerifyMIC(), GSS_Wrap()
GSS_GetMIC() _after_ calling GSS_Delete_sec_context() ?

Nope.

That GSS_Unwrap() or GSS_VerifyMIC() still works is at least somewhat
unlikely for "regular" context deletion tokens, but guaranteed for
context error tokens that report a context establishment failure.

A gssapi mechanism that would have GSS_Wrap() or GSS_GetMIC() work after
processing a context deletion token would be somewhat silly, because
the mechanism knows _reliably_ that there exists noone that could
process the results.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Mon, 15 Dec 2014 22:59:39 +0100 (CET)

Sorry, fixing a typo and clarifying.

The "early message protection" facilities will only ever succeed
for early message protection (gss_wrap(), gss_getmic()), but will _never_
succeed for early message un-protection (gss_unwrap(), gss_verifymic()).

-Martin

I wrote:
> unlikely for "regular" context deletion tokens, but guaranteed
++ to fail for

---

From: Nico Williams <[email-masked]>
Date: Mon, 15 Dec 2014 17:07:24 -0600

> GSS_GetMIC() _after_ calling GSS_Delete_sec_context() ?

No, after calling GSS_Process_context_token().

---

From: Nico Williams <[email-masked]>
Date: Mon, 15 Dec 2014 17:13:45 -0600

> succeed for early message un-protection (gss_unwrap(), gss_verifymic()).

RFC2743, page 26, contradicts you on this:

   For context establishment calls, this state Boolean is valid and
   interpretable when the associated major_status is either
   GSS_S_CONTINUE_NEEDED, or GSS_S_COMPLETE.  Callers of GSS-API (both
   initiators and acceptors) can assume that per-message protection (via
-> GSS_Wrap(), GSS_Unwrap(), GSS_GetMIC() and GSS_VerifyMIC()) is
   available and ready for use if either: prot_ready_state == TRUE, or
   major_status == GSS_S_COMPLETE, though mutual authentication (if
   requested) cannot be guaranteed until GSS_S_COMPLETE is returned.

And this makes plenty of sense too.  Consider a mechanism that does a
key exchange using ephemeral-ephemeral DH in one round trip but
nonetheless requires several more round trips to complete
authentication.  The early prot_ready protection could be available
several context tokens prior to full establishment, and this could
be quite useful.

For example, ABFAB can require multiple round trips to authenticate, but
it could be modified to support (and maybe already does) early
prot_ready using DH.

Nico
--

---

From: [email-masked] (Martin Rex)
Date: Tue, 16 Dec 2014 11:02:17 +0100 (CET)

> No, after calling GSS_Process_context_token().

It seems I was tired last night.

I meant to say:

 You mean calling GSS_Unwrap(), GSS_VerifyMIC(), GSS_Wrap()
 GSS_GetMIC() _after_ calling GSS_Process_sec_context() ?

-Martin

---

From: Nico Williams <[email-masked]>
Date: Tue, 16 Dec 2014 09:47:18 -0600

>  GSS_GetMIC() _after_ calling GSS_Process_sec_context() ?

Yes.

Because of out of order delivery of tokens in, say, a UDP-based app it's
certainly possible for GSS_Unwrap() and GSS_VerifyMIC() to be needed
after calling GSS_Process_sec_context().

GSS_Pseudo_random(), of course, should also continue functioning after
processing an error token.  (For the same reason that GSS_Unwrap() and
GSS_VerifyMIC() should.}

The logic by which I conclude that GSS_Wrap() and GSS_GetMIC() can also
be called after calling GSS_Process_sec_context() is this: error tokens
do not prove that peer delete their security context, and if they had
been PROT_READY, they could still continue (though I grant that it would
be rather weird to do so).

GSS_Process_sec_context() should just do what its name says, and it
should disable no security context functionality.

So, I'm coming around to Greg's position, though for different reasons
than his.

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 16 Dec 2014 11:02:00 -0500 (EST)

> Okay, so now we're looking at:

Thinking about things a bit more with a clearer head, I would like to
replace "last context token" with "last context establishment token" in
this paragraph, since error and deletion tokens are still context-level
tokens, and the one which we thought was last isn't actually last if
there's an error token in reply to it, so calling it the "last
context(-level) token" is strange.

[...]

>      when the latter returns GSS_S_COMPLETE or GSS_S_FAILURE.

[peeking ahead in the thread, since I'm replying to an early message]

I think the disagreement between Greg and Nico can be distilled to: how
likely are we to require that future extensions using async context tokens
are implemented in a backwards-compatible way?

Taking the rekey example as a strawman (even though we know that there are
other ways to do it not involving async context tokens), this would just
mean that a GSSv2u3 app would try to do the rekey, and if it was talking
to a GSSv2u1 app, the rekey would fail, and the old key would
transparently continue to be used.

So, it is certainly possible to be backwards compatible, at least in some
cases.  Greg's argument that there should also be application-level error
handling which could discover that the context is unusable and tear things
down rings true to me, so I agree with Greg that we should not close the
door prematurely.

-Ben

---

From: Nico Williams <[email-masked]>
Date: Tue, 16 Dec 2014 10:44:31 -0600

> context(-level) token" is strange.

The problem is "last" then.  The addition of "establishment" doesn't
cure the problem.  IMO it's a non-problem.

> are implemented in a backwards-compatible way?

Sort of.  But the key is that we shouldn't REQUIRE that the next step be
getting into a state that leads inexorably to calling
GSS_Delete_sec_context().

We don't, as this RFC doesn't use RFC2119.  Greg things that "...should
generally call GSS_Delete_sec_context()..." is too strong.

It's a bit of an angels on a headpin argument... if we assume that all
properly function applications will inexorably end up calling
GSS_Delete_sec_context() anyways (they should, if they succeed as
establishing a security context).

I believe the "generally" weasel word is good enough.  I don't think the
entire paragraph should be excised.  I'd like to see alternative text
from Greg.

> transparently continue to be used.

Or the v2u1 app would end up calling GSS_Delete_sec_context().  It's not
at all clear to me that we want a v2u1 app to continue in the case of a
re-key attempt that fails because it (the app) doesn't know that that's
what the context token was about (or how to respond to it).

Of course, the thought occurs that a re-key context token would elicit a
GSS_S_DEFECTIVE_TOKEN major status code from GSS_Process_context_token(),
so maybe there's no real problem here (since the "should generally" text
above does not apply in that case).

> down rings true to me, so I agree with Greg that we should not close the

I believe the above text does not do this.  See above comment about
GSS_S_DEFECTIVE_TOKEN.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 16 Dec 2014 10:50:23 -0600

> above does not apply in that case).

The further thought occurs that a v2u1 app might be using a v2u1+N
GSS-API implementation (there's no version negotiation between the two).

For the case of re-keys (if we ever implement re-key with extra async
context tokens) we must then... what? introduce a new major status code
for GSS_Process_context_token()?  I think that would do.

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 16 Dec 2014 19:07:02 +0000

Meta question: if it requires so much discussion is this
really suited as an erratum? Just wondering:-)

S.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 16 Dec 2014 14:53:26 -0500 (EST)

> really suited as an erratum? Just wondering:-)

Well, I think the crux of it is that the thing which is inspiring so many
words is not really suited as an erratum, but that's only a small part of
the actual proposed text.

The main goal is to fix the broken behavior of
GSS_Process_context_token(), which as written in RFC 2743 does not allow a
caller to obtain information from a processed error token.  (If that's the
case, there's no reason to specify error tokens, so it's clearly a bug.)

However, the proposed text also adds this paragraph:

which is adding new text which attempts to clarify how applications
consume the GSS-API.  It is this paragraph which is controversial, and it
is perhaps not appropriate for an erratum.  We may be better off both
consensus-wise and process-wise if we eliminate this paragraph and leave
the current description of how to call GSS_Process_conetxt_token() as it
is in RFC 2743.  (Nico will probably say that "generally" is wiggle room
so this is not actually normative, but even with that, it's not clear that
this paragraph adds enough to merit inclusion in an erratum.)

Skipping that paragraph would allow us to move forward and fix the clear
brokenness in the spec, without being bogged down trying to resolve a
different apparent ambiguity.

-Ben

---

From: [email-masked] (Martin Rex)
Date: Tue, 16 Dec 2014 22:55:44 +0100 (CET)

> RFC2743, page 26, contradicts you on this:

No, this does not really contract me.  :)

>    requested) cannot be guaranteed until GSS_S_COMPLETE is returned.

The original purpose, semantics and security guarantees of GSS-API
per-message protection services are *NOT* changed by PROT_READY.
 
The original purpose and semantics (quoting rfc2743):

   Per-message GSS_Wrap() and GSS_Unwrap() calls provide the
   data origin authentication and data integrity services which
   GSS_GetMIC() and GSS_VerifyMIC() offer, and also support selection of
   confidentiality services as a caller option.

or another quote from rfc2743:

   The GSS-API per-message integrity and data origin authentication
   services provide assurance to a receiving caller that protection was
   applied to a message by the caller's peer on the security context,
   corresponding to the entity named at context initiation.  The GSS-API
   per-message confidentiality service provides assurance to a sending
   caller that the message's content is protected from access by
   entities other than the context's named peer.

PROT_READY was never conceived to preempt any actually requested
authentication or to neuter message protection services from 
data origin authentication--in case that this characteristic will be
provided should security context establishment succeed with GSS_S_COMPLETE.

rfc2743 acknowledges that prot_ready may cause message (un)protection
to precede _confirmation_ of mutual authentication (back to the initiator),
but not preempt mutual authentication (allowing the acceptor to get
at the contents of confidentiality protected messages without actually
succeeding authentication when mutual authentication is requested.

What is a little less clear: what does this mean for the "simple"
form of authentication, the unidirectional authentication from
initiator to target, for gssapi mechanisms other than, say, Kerberos.

> 
> And this makes plenty of sense too.

I have my doubts.  In the original design, TLS also does not allow
application data to be sent prior to the verification of the
server's Finished handshake message.  There are hacks such as FALSE START,
but AFAIK they at least still try to ensure not to leak application data
to the server unless the server can successfully complete the TLS handshake
(i.e. pass the authentication).  Only confirmation of the Server passing
the handshake gets delayed.

>
> Consider a mechanism that does a key exchange using ephemeral-ephemeral
> DH in one round trip but nonetheless requires several more round trips
> to complete authentication.  The early prot_ready protection could be
> available several context tokens prior to full establishment,
> and this could be quite useful.

And it will provide *MORE* than enough rope to apps to hang themselves...

-Martin

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 16 Dec 2014 23:10:00 +0000

> different apparent ambiguity.

Could be a plan - don't forget that it's entirely possible to file
a 2nd or 3rd or N-th erratum after the first is finalised.

Cheers,
S.

---

From: Greg Hudson <[email-masked]>
Date: Wed, 17 Dec 2014 17:26:55 -0500

> door to specifying context tokens which don't.

Let me rephrase this objection:

I think the scope of this erratum should be limited to making it
possible for conforming gss_process_context_token implementations to
convey peer error token information to callers.  As Ben said yesterday,
the inability to do so is a clear defect in the spec, which makes it
appropriate fodder for an erratum.

The proposed text goes beyond that scope by giving guidance on how to
respond to GSS_S_COMPLETE.  That guidance assumes that async context
token types are limited to the ones mentioned in section 2.2.4:
(deletion tokens and error tokens resulting from the final synchronous
token).  Because this assumption does not match my reading of the
existing text, I don't think providing such additional guidance about
GSS_S_COMPLETE is appropriate for an erratum.  I also don't think
clarifying this point is important enough to justify a document revision.

---

From: Nico Williams <[email-masked]>
Date: Wed, 17 Dec 2014 17:05:11 -0600

> appropriate fodder for an erratum.

This rationale for excluding the above is less objectionable to me than
the original.  I would rather say what the application should do in the
GSS_S_COMPLETE/FAILURE cases, and I thought (and still thing) that
"should generally" or some such weasel verbiage ought to be an
acceptably non-normative way to do this.  But if this is the only way to
make progress on this erratum, I'll accept it.

> clarifying this point is important enough to justify a document revision.

I think that the [mostly implied, in the base GSS RFCs and our work
since then] that the extensibility model for the GSS-API (the API _and_
the protocol pattern it sets out) is such that the door to the sorts of
extensions you had in mind is closed without negotiation of their use.

That means that the possible unexpected context tokens can only be error
and context deletion tokens unless the application (and mechanism)
negotiate the availability of new unexpected context token types (e.g.,
via a req_flag/ret_flag).

If there's no consensus as to the GSS extensibility model then I think
it's fair to say that there's no consensus to include the above text in
the erratum, but if there is consensus as to the GSS extensibility model
then I don't see much reason to reject the above text -- just a question
of expediency.  I do think it's better to give guidance here -even the
opposite of that which I'd give- than none.

Finally, if there's no consensus as to the GSS extensibility model then
we're going to have more problems in the future.  I don't know what we
can do about that without more (and more active) participants to help
define a consensus about a GSS extensibility model in a future RFC.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 19 Dec 2014 18:16:38 -0600

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.

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 31 Dec 2014 17:34:11 -0500 (EST)

> |      GSS_Process_context_token() returns GSS_S_FAILURE.

I suppose I could live with this, but I still don't see how it's actually
adding enough to merit inclusion in an erratum.

That is, the application is going to be calling GSS_Delete_sec_context()
eventually anyway, so we're just saying that failures of
Process_context_token() should (generally) fail the whole context
(immediately).  Would application authors (generally) do anything else
upon presented with a GSS_S_FAILURE from Process_context_token()?  It
seems like it is just calling out a specific case of what people should
already be doing, which is not tied to the key component of the erratum.

-Ben