Project review: GSS credential store extensions
nico at cryptonector.com
Thu Jul 12 13:00:13 EDT 2012
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
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.
More information about the krbdev