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

[[e-mail] (Martin Rex)]

Jeffrey Hutzelman wrote:
> On Mon, 2014-01-20 at 20:32 +0100, Martin Rex wrote:
> > Nico Williams wrote:
> > > 
> > > 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.
> > 
> > In theory yes, but practice may differ.
> > 
> > What I'm afraid of is wrapper functions that look like this:
> 
> Well, if an app has such a wrapper, then the _wrapper_ is not safe to
> call twice.  That really has nothing to do with whether
> gss_release_buffer is safe to call twice, and the spec for the latter
> pretty clearly says it modifies its output.

I disagree.

Potentially we're fighting about the difference of
"call-by-value" vs. "call-by-reference" in C, and what exactly 
is the meaning of "same foo" when call-by-reference is used.

Does "same same" apply when the value is the same. or only when both
value and reference/address are the same?

With that in mind, a comment like

>
> /* It is safe to call gss_release_buffer twice on the same buffer. */

is ambiguous and wrong.  Discounting empty buffers, calling
gss_release_buffer with the same buffer (=same value) more than
once is very very probably unsafe. 

And the fact that gss_release_buffer() is supposed to *CHANGE* the
buffer (struct) value should make it clear that the concept of
"same buffer" is somewhat unnatural to the GSS-API C-Bindings.


What should be safe is calling gss_release_buffer() with an empty
buffer.  So the important guidance would be to *ALWAYS* create
gss_buffer_desc structures initialized with {0, 0} in C.


The notion that gss_unwrap() could return a zero-length token is
also somewhat flawed.  gss_unwrap() returns a message (=app data)
if anything. There are no such things as zero-length tokens anywhere
throughout GSS-API.  And a gssapi mechanism should definitely not
rely on the application caller to call gss_release_buffer() on a
zero-length message returned from gss_unwrap().  The only sane
representation of an empty buffer _output_ value from a gssapi mech
is {0, 0}, i.e. be conservative in what you send (=give out).


> 
> > > 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.
> > 
> > correct -- gss_unwrap() may return a zero-length output buffer.
> > The length of the buffer must be zero for obvious reasons.
> > The value of the pointer is then irrelevant, and the gssapi
> > mechanism must be able to cope safely with whatever it returns
> > along with a zero length.
> 
> Right.  If the mech returns a buffer with zero length and a non-NULL
> value pointer, then it must be able to cope with gss_release_buffer
> being called on that buffer.
> 
> 
> > 
> > 
> > >
> > > 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,
> > 
> > Nope, neither of these three calls can return a zero-length output token,
> 
> You know, we've discussed that question on several occasions, and I
> can't remember ever being able to find something in RFC2743 that says
> that.  The C bindings happen to make it impossible to tell the
> difference between no token and an empty token, which makes using empty
> tokens impractical, but if you can find text that prohibits them, please
> do point it out.

As mentioned above, the GSS-API does not have the concept of
zero-length _tokens_.  Either there is a token, or there is no token.
The reason is simple: you can not securely convey a zero-length token
over an insecure communication channel.  This is why gss_get_mic()
and gss_wrap() must produce non-zero tokens even for zero-length
messages.


-Martin