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

[Nico Williams <[e-mail]>]

I'm an idiot.  I missed the "encouraged" part somehow.

Nonetheless, it seems clear that the intention is that calling a
gss_release/delete_*() function will modify the input/output parameter
so that calling it again is safe, so that releasing a zero-length,
non-zero valued buffer ought to be safe.  The API can output
zero-length buffers from gss_unwrap(), so the question comes up of
whether such buffers can have non-zero values -- the RFC doesn't say.
The other places where the API can output a zero-length token in
non-error conditions are gss_init/accept_sec_context() and
gss_delete_sec_context, and there the text is not entirely
dispositive...  but it is highly suggestive that zero-length tokens
are empty, and this, together with the general design of
gss_release/delete_*() strongly implies that it should be safe to call
any of those twice with the same input/output parameter.

The only reason to assume that releasing a zero-length/non-zero value
buffer is that an implementation might have called malloc(0) in the
process of outputting a zero-length buffer from gss_unwrap(), and the
malloc() implementation happens to return non-NULL when called with
zero as its argument.  That's clearly a bug.  There should be no
reason to release empty buffers.

At any rate this is all rather incidental to Ben's I-D and doesn't
need to be addressed at this time.  If we ever update RFC2744, I would
insist on changing that "encouraged" to "MUST" with some text about
how earlier versions of the API did not have that requirement,
therefore applications SHOULD zero the value in the buffer after
releasing it.

Nico
--