Re: [kitten] New Version Notification for draft-kaduk-kitten-gss-loop-02.txt (fwd)

[Greg Hudson <[e-mail]>]

On 01/14/2014 04:55 PM, Benjamin Kaduk wrote:
> I made some minor edits to the body text and trimmed down the sample
> code to be more consistent with Greg's suggestions.  I think Greg wants
> the sample code trimmed even further (i.e., to not have anything in the
> bodies of the {send,receive}_token functions, and possibly not have them
> at all, but I prefer to be more concrete.

My reasoning is that we cannot be concrete in a way which will be useful
to very many applications.  Currently your stub send_token() and
receive_token() functions accept fd arguments, for instance, while a
typical caller would have some more complicated connection state object.

On a similar note, typical callers probably won't want to use warnx().

> Is it reasonable to adopt this document as a working-group draft at this
> time?

I think it is reasonable.  To recap, the goal here is to reduce the
amount of verbiage that protocol standards (AFS, LDAP, etc.) must use to
describe how implementors should use GSSAPI, by giving them something
they can refer to.

> I am becoming more convinced that we should have Java sample code as
> well as C

I think that would be a fine thing, but shouldn't block the draft from
progressing.

> Finally, the C sample code has a comment (in two places, actually):
> /* It is safe to call gss_release_buffer twice on the same buffer. */
> This could potentially be misleading, as I believe our conclusion was
> that 2743/2744 do not explicitly require this to be safe.  However, we
> believe that it is safe in all known implementations, and that an
> implementation where it was not safe would be very difficult to use
> correctly.  Is it reasonable to leave this comment in place under the
> reasoning that it is describing the assumptions made by the sample code
> (as opposed to describing the behavior mandated by the specification)?

I think it's reasonable to retroactively standardize this behavior of
gss_release_buffer, if it's a property of every implementation we're
aware of.

But if we're not going to do so (because gss-loop isn't a normative
document and we're not prepared to issue a 2744 update), then I don't
think it's appropriate for the sample code in gss-loop to be making that
assumption.  Unfortunately, I don't know of a nice elegant way to
restructure the code so that the assumption isn't necessary.