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

[Nico Williams <[e-mail]>]

On Wed, Nov 20, 2013 at 07:40:28PM -0500, Benjamin Kaduk wrote:
> On Thu, 21 Nov 2013, Martin Rex wrote:
> >It is up to the mechanism implementation at which point during the
> >handshake the src_name output parameter from gss_accept_sec_context()
> >is populated.  The application caller MUST provide the exact same
> >parameter as src_name to *ALL* iteration calls of gss_accept_sec_context()
> 
> Having recently completed a re-read of RFC 2743 and RFC 2744 (*),
> I'm sad to say that I do not believe there is a normative reference
> to support the MUST, there.  I really wish there was, but RFC 2743
> only calls out the acceptor_cred_handle as being fixed between
> iterations.

Well, no other interpretation is sensible but the one that Martin gave.
Anything else surely would have been mentioned, and, at any rate, would
not be sensible.

Why would the name of the initiator *as output to the application* vary
as the security context token exchange progresses?

Clearly allowing that makes no sense.  That's not to say that the
mechanism might not learn the initiator's name piecemeal, just that it
can't output it piecemeal.

> Hmm, I guess this is relevant, though:
>    [...] verifies the incoming input_token and
>    (following the successful completion of a context establishment
>    sequence) returns the authenticated src_name and the mech_type used.
> So, that would indicate that src_name is only valid after successful
> context establishment.

Authentication is only complete when security context establishment
completes.  Until then anything that may be available (e.g., PROT_READY,
channel binding state -- any and all ret_flags, src_name) is not
authenticated.  (The one exception that might make sense might be
deleg_cred, but there's no purpose to treating it as an exception.)

> >>We discussed whether (either at the abstract level or the C bindings) it
> >>is guaranteed to be safe to call gss_release_buffer() twice on the same
> >>buffer.  It is required to set the length of the buffer to zero (but not
> >>to zero the value field), but also "Any buffer object returned by a
> >>GSS-API routine may be passed to gss_release_buffer (even if there is no
> >>storage associated with the buffer)."  What exactly constitutes a "buffer
> >>object returned by a GSS-API routine" seems subject to interpretation.
> >
> >What in particular causes your notion "seems subject to interprettion"?
> 
> Nico was making arguments about how it is "torturing the language
> and common sense" to claim that gss_release_buffer() is "notionally
> output[ting] a buffer".  I was claiming that (in the C bindings at
> least), the buffer parameter is an output parameter of
> gss_release_buffer().

"Output" is an [notional] attribute of the function argument in the GSS
abstract API and in the C bindings, not an attribute of the buffer type
(sadly).  The buffer is only an output of gss_release_buffer() in that
this notionally permits gss_release_buffer() to modify the buffer.

IF RFC2744 had specified proper const typedefs then we'd not say that
the buffer is an output of that function, just that the input to it is
not of a const type.  And then the const-/not-const-ness of an argument
would not merely be notional; it'd be specified in a way that the C
tooling can understand.

It is torturing the language to say that gss_release_buffer() outputs a
token.  It does not.  It modifies a buffer structure to mark it as
"empty", but that's it.

There is a problem in that RFC2744 says that gss_release_buffer() must
set the buffer's length to zero but only that it may set the pointer to
NULL.  This is a problem because malloc(0) may return a non-NULL pointer
that must be free()ed, and so gss_release_buffer() called with a
zero-length, non-NULL value buffer might well call free() on that value!

Now, obviously the foregoing is not a problem because a) apps shouldn't
be double-releasing things, and b) because providers shouldn't be
idiotic: they must either set the value to NULL on buffer release or not
free() it when length is zero (preferably both).

Nico
--