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

[Nico Williams <[e-mail]>]

On Wed, Nov 20, 2013 at 08:45:10PM -0500, Benjamin Kaduk wrote:
> On Thu, 21 Nov 2013, Martin Rex wrote:
> >Well, OK, my rule-of-thumb fails in this special case for rfc2744.
> >
> >The abstract semantics of rfc2743 for GSS_Release_buffer() _still_
> >apply to the rfc2744 gss_release_buffer() language bindings.

I agree.

Some details might naturally differ from RFC2743 for other language
bindings, but at the end of the day they must roughly agree.  In
particular there are some important aspects:

 - outputs of security context establishment are only valid or
   authenticated when the context establishment completes

 - no language binding can change the synchronous nature of security
   context token exchanges

 - all the base features must be there (some mechs/providers might not
   provide some features, such as, e.g., confidentiality protection, but
   the programming language bindings of the abstract API  must make it
   possible to provide those)

 - the providers own output buffers

 - the app owns input buffers

There's probably more.

Things are are not obviously required of bindings include things like
manual memory management.  Indeed, automatic memory management is not
incompatible with the abstract API.

> I guess that's compelling, the 2744 text describing
> gss_release_buffer's applicability notwithstanding.

Yes.

> So, we're left with Greg's assessment, "it is not safe per the spec,
> although it is probably safe in every GSSAPI implementation."

And: apps shouldn't be double-releasing anything.

> Do we want to change the sample code to not rely on this behavior,
> or just note that it does so rely?

Either way is fine with me.

Nico
--