Project review: GSS credential store extensions

[Nico Williams]

On Thu, Jul 12, 2012 at 11:12 AM, Greg Hudson <ghudson at mit.edu> wrote:
> On 07/12/2012 10:19 AM, Sam Hartman wrote:
> 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.

Oh, well, good point.  I suppose I can live with this answer regarding
memory management (the mechglue copies).

> 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.

Not default, *current*.

>> 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.

I don't mind this.  In practice the pattern that repeats is trivial to
wrap in a macro.

>> 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

Simo doesn't care for this, IIRC.  I'm the one who wants some sort of
indicator of the source of a given URN, so that the mechanism can
refuse to allow passwords that weren't prompted for, say.

> 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

And if there were a way to ask the mechanism what URNs it wants then
this could form the basis of a simple but effective interactive
initial credential acquisition facility.  Calling this a cred store at
that point is a bit of a stretch...

> credentials" could include internal nulls (for instance, the key from a
> keytab), while credential locations typically would not.

Yes, though re: internal NULs and const char *, just hex encode the
thing.  Though if we really see this coming then we have a stronger
argument for using buffers.

Nico
--