Project review: GSS credential store extensions

[Greg Hudson]

On 07/12/2012 10:19 AM, Sam Hartman wrote:
> I'd like to speak in support of const char * here at least for the URN
> parameter.

I believe this came up earlier, though I can't find a record of it.  No
one from the GSSAPI community seemed to favor buffers.

> We should also think about the use of an elements struct in terms of our
> experience with GSS-API memory allocation.  As designed today all the
> element struct manipulation is left up to the application. The down
> sides there are that it makes it expensive and messy if the mechglue or
> a stacked mechanism wants to manipulate the element set.

Nico brought this up on kitten and I (and Simo) disagreed.

I know everyone wishes buffers were different (though I'm not sure how)
because of the twin problems that (1) applications call
gss_release_buffer on buffers they themselves allocated, creating memory
bugs, and (2) the mechglue returns buffers allocated by either itself or
a mechanism, and can't tell which one when it comes time to release.

(2) is only a problem because buffers are used for wrapped and unwrapped
messages, which we don't want to take the extra time to copy.  If it
weren't for that, the mechglue could avoid returning mech-allocated
buffers to the caller.  Since cred stores are not used for
performance-sensitive GSS calls, I don't think that problem applies here.

Both problems only apply if we start communicating cred stores to the
caller instead of vice versa.  All of the suggestions I saw for which we
might do this--like asking for the default cred store location of a
mechanism--were ideas I didn't particularly like.

> Also, it forces
> applications to do a bunch of redundant memory management and everyone
> is probably going to write there own release functions.

This cuts both ways.  If the application happens to have a way of simply
managing its cred store content pointers, then making the cred store
type opaque forces it to do a lot of extra work and check a lot of error
conditions.

> Is this intended to replace gss_acquire_cred_with_password? I.E. can I
> "get" a credential from a password, or a password and smart card, or a
> PIN and smart card? I'm not asking whether you plan to implement that so
> much as whether that usage is compatible with this architecture.

I believe Simo's intent is to leave the door open to this with "the
store can specify both the actual credentials and/or the credential
location."  Personally, I'm not sure it's a good idea.  It would let you
supply a richer set of secrets than just a password, but only if you
know what secrets you need to provide ahead of time.  Also, "the actual
credentials" could include internal nulls (for instance, the key from a
keytab), while credential locations typically would not.