Subject: [kitten] RFC2743 errata 4251

From: Nico Williams <[email-masked]>
Date: Tue, 4 Nov 2014 14:47:15 -0600

I wrote this yesterday but neglected to click the submit button.  Just
submitted:

http://www.rfc-editor.org/errata_search.php?eid=4151

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 6 Nov 2014 14:20:01 -0500 (EST)

> http://www.rfc-editor.org/errata_search.php?eid=4151

It was probably a little premature to submit while discussion was still
ongoing.  We could probably wordsmith things a little better, but this
looks consistent with the (3a) from my list.

And of course it neglects the possibility of (rare) local errors like
ENOMEM.

That said, I do not think I have any strong objections to any portion of
it.

-Ben

---

From: Nico Williams <[email-masked]>
Date: Thu, 6 Nov 2014 14:24:34 -0600

> looks consistent with the (3a) from my list.

Well, it can't be too premature to file the erratum: it has to be
discussed regardless.

> And of course it neglects the possibility of (rare) local errors like

Yes, but since either way the context has to be deleted... no harm
results.  (Also, the peer isn't likely to send an error token saying
ENOMEM, not if it has to allocate memory to make it.)

> That said, I do not think I have any strong objections to any portion of

I think this is likely the consensus.  Do we need a formal call for
consensus?  Do we want to use the erratum for that and wordsmith it
first?

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 6 Nov 2014 20:50:50 -0500 (EST)

> consensus?  Do we want to use the erratum for that and wordsmith it

I think that's in the AD's court, so let's wait a bit.

-Ben

---

From: [email-masked] (Martin Rex)
Date: Sat, 8 Nov 2014 02:48:20 +0100 (CET)

> http://www.rfc-editor.org/errata_search.php?eid=4151

I hate to do this (to you), but I'm "violently" opposed to this errata.

I believe you have misunderstood the meaning of the original text.

Quoting from your errata:

  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 peer had an error consuming the
   last context token sent to it (when the local side must have been
   fully established but the peer hadn't yet been).  The minor status
   code provides error information from the input token.

You find similar descriptions for GSS_S_FAILURE semantics all over
the GSS-API specification _on_purpose_, and you _may_not_ remove that
meaning here.

You may at most add a hint that the minor_status(!!) that must
accompany a GSS_S_FAILURE major_status returned from
gss_process_context_token() may not just cover reasons that are
a "local matter" (i.e. implementation issue of the current gssapi
mechanism) but include reasons conveyed through an error token
from the remote side.  It will be impossible to define portable
behaviour to programmatically react to specific such reasons,
because what will be returned is not just a local issue, but
a remote plus local issue combined.

And Ben is right that GSS_S_FAILURE is explicitly supposed to include
situations of local resource shortage (no more memory, no more filehandles,
no more socket handles, whathaveyou).

Btw. any minor_status that conveys an error from a remote peer that
was carried in an error token ought to clearly say that this information
came from the remote peer (and is not a local error) in the textual
translation from gss_display_status().

-Martin

---

From: Nico Williams <[email-masked]>
Date: Mon, 10 Nov 2014 10:25:07 -0600

> I hate to do this (to you), but I'm "violently" opposed to this errata.

Hey, at least you hated doing it!

> I believe you have misunderstood the meaning of the original text.

Perhaps.  The goal is to explain how to process an unexpected error
token.

> the GSS-API specification _on_purpose_, and you _may_not_ remove that

Fair enough, we'll add text rather than replace text.

> a remote plus local issue combined.

I agree.

> was carried in an error token ought to clearly say that this
> information came from the remote peer (and is not a local error) in
> the textual translation from gss_display_status().

Indeed.

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 24 Nov 2014 13:31:30 -0500 (EST)

> Fair enough, we'll add text rather than replace text.

Nico, do you plan to come up with text for an alternate proposal?

Stephen can make the changes once we have text we're happy with.

-Ben

---

From: Nico Williams <[email-masked]>
Date: Mon, 24 Nov 2014 12:33:49 -0600

> Nico, do you plan to come up with text for an alternate proposal?

Yes, I do (I was hoping Martin might :).

> Stephen can make the changes once we have text we're happy with.

OK.

---

From: Nico Williams <[email-masked]>
Date: Mon, 24 Nov 2014 12:51:16 -0600

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

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

Nico
--